1 |
hasufell posted on Mon, 19 Oct 2015 19:13:50 +0200 as excerpted: |
2 |
|
3 |
> On 10/19/2015 07:08 PM, Rich Freeman wrote: |
4 |
>> On Mon, Oct 19, 2015 at 11:27 AM, Ian Stakenvicius <axs@g.o> |
5 |
>> wrote: |
6 |
>>> |
7 |
>>> Ahh, so what you're referring to here is stabilization of multiple |
8 |
>>> unrelated packages in a single commit.. ok.. i'm not so comfortable |
9 |
>>> with that idea.. |
10 |
>> |
11 |
>> Nor am I. A commit should be a set of related changes. Stabilizing |
12 |
>> all of KDE-n in one commit makes a lot of sense. Stabilizing 5 random |
13 |
>> packages in one commit doesn't make sense. By all means push them all |
14 |
>> at once, but don't commit them all at once. It isn't like we have to |
15 |
>> pay for each commit. |
16 |
>> |
17 |
> We already know that. But if e.g. ago runs his scripts at 00:00 with |
18 |
> ~300 packages stabilized, the history (without git command line) on |
19 |
> github/gitweb will be fun to read (and people DO that). |
20 |
|
21 |
I'm one of those people (see my reply a few posts down-thread], tho I |
22 |
don't read /everything/, but would definitely read rather more if this |
23 |
were handled correctly. |
24 |
|
25 |
But IMO, the proposal here is trying to fix the bit that's /not/ broken, |
26 |
not what is. |
27 |
|
28 |
On the kernel, I can very easily do a ... |
29 |
|
30 |
git log --color --stat --graph ORIG_HEAD.. |
31 |
|
32 |
... get the nice color graphical listing piped to most, hit end to read |
33 |
the whole range of commit logs into buffer, and then starting from the |
34 |
end, pageup one page at a time to get the merge chronology correct, and |
35 |
read all of Linus's very nicely summarized merge commits, telling me what |
36 |
trees were merged and listing the one-line title/summary for each one. |
37 |
|
38 |
If I want to drill down, as I generally do for specific subsystems |
39 |
(fs/btrfs, drm/radeon, various subsystems like power I've had bugs with |
40 |
in the past), it's a multi-level hierarchy and thus easy enough to go |
41 |
from say the drm merge to the radeon sub-merge and check individual |
42 |
commits at the comment and affected file levels (--stat). |
43 |
|
44 |
If I want to drill down further, the commit ID is right there and I can |
45 |
git show <ID> to read the specific code. |
46 |
|
47 |
Meanwhile, if the top-level merge commit says it's for example arm, I'll |
48 |
immediately move on to the next top-level merge commit, effectively |
49 |
skipping all those possibly hundreds of "boring and not interesting to |
50 |
me" individual arm commits, by very simply skipping to the next very |
51 |
nicely commented merge commit, with its one-liner list of individual |
52 |
commits. |
53 |
|
54 |
The merge hierarchy, informative merge commit comments, and color-coded |
55 |
--graph makes finding the merges so easy! That's the way git was |
56 |
/designed/ to work. =:^) |
57 |
|
58 |
|
59 |
Unfortunately, gentoo is by policy trying to flatten all that multi-level- |
60 |
hierarchy-for-a-reason into a single flat list of CVS/SVN-like strictly |
61 |
ordered parent-child relationship commits, destroying the whole rich |
62 |
hierarchy and all the information that git includes with it, using |
63 |
horrible rebase-pushes as an incredibly poor substitute for the very |
64 |
natural git-native merge hierarchy along with all its richness. |
65 |
|
66 |
|
67 |
Now we're complaining about how flat/boring/uninformative all those |
68 |
atomic commits are, but it's not the atomic commits that are the problem, |
69 |
it's the fact that we're deliberately stripping out the merge commits and |
70 |
all the richness that comes with them, including the natural hierarchy |
71 |
and the ability to make those merge-commits as informative as they |
72 |
normally are in the kernel, with a short mention of the highlights and a |
73 |
quick list of the included one-liners. |
74 |
|
75 |
|
76 |
If gentoo were doing git the way it was designed to work instead of |
77 |
trying to force it into the one-dimensional CVS mold, ago's 300-commit |
78 |
bore for anyone not interested in that subsystem, on gentoo commit after |
79 |
boring one-dimensional commit that's of less interest to me than the |
80 |
price of tea in China, would be in a single merge tree with the arch team |
81 |
in the one-liner, so I could immediately skip on to the next top-level |
82 |
merge. Pageup to that merge, spotted quickly by the asterisk in the left |
83 |
column, the two lines merging to it, and the change in color in the left- |
84 |
hand-line, see it's of no interested, and on to the next one, instead of |
85 |
having to go thru 300 boring one dimensional commits in case something |
86 |
I'm interested in squeezed in there somewhere. |
87 |
|
88 |
So as I said, the problem isn't the atomic commits, it's gentoo's |
89 |
strongly recommended lack of merge hierarchy. Now we're complaining |
90 |
about that and trying to kill the atomic commits, but they're not the |
91 |
problem, trying to use that new git nailgun as if it's the manual |
92 |
screwdriver of yesteryear is the problem. If we don't fix that, we'll |
93 |
simply be trying to replace one small bit of the information we so |
94 |
mercilessly stripped out with those forced-to-one-dimension rebases, |
95 |
instead of deciding that stripping all that information out in the first |
96 |
place wasn't such a good idea after all and that the real solution is to |
97 |
simply stop trying to use that power nailgun as a manual screwdriver! |
98 |
|
99 |
-- |
100 |
Duncan - List replies preferred. No HTML msgs. |
101 |
"Every nonfree program has a lord, a master -- |
102 |
and if you use the program, he is your master." Richard Stallman |