[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    [gentoo-dev] Re: stabilization commits and atomicity
From:       Duncan <1i5t5.duncan () cox ! net>
Date:       2015-10-20 23:16:26
Message-ID: pan$65f2b$4074604e$e602289b$ac3bb3de () cox ! net
[Download RAW message or body]

hasufell posted on Mon, 19 Oct 2015 19:13:50 +0200 as excerpted:

> On 10/19/2015 07:08 PM, Rich Freeman wrote:
>> On Mon, Oct 19, 2015 at 11:27 AM, Ian Stakenvicius <axs@gentoo.org>
>> wrote:
>>>
>>> Ahh, so what you're referring to here is stabilization of multiple
>>> unrelated packages in a single commit..  ok..  i'm not so comfortable
>>> with that idea..
>> 
>> Nor am I.  A commit should be a set of related changes.  Stabilizing
>> all of KDE-n in one commit makes a lot of sense.  Stabilizing 5 random
>> packages in one commit doesn't make sense.  By all means push them all
>> at once, but don't commit them all at once.  It isn't like we have to
>> pay for each commit.
>> 
> We already know that. But if e.g. ago runs his scripts at 00:00 with
> ~300 packages stabilized, the history (without git command line) on
> github/gitweb will be fun to read (and people DO that).

I'm one of those people (see my reply a few posts down-thread], tho I 
don't read /everything/, but would definitely read rather more if this 
were handled correctly.

But IMO, the proposal here is trying to fix the bit that's /not/ broken, 
not what is.

On the kernel, I can very easily do a ...

git log --color --stat --graph ORIG_HEAD..

... get the nice color graphical listing piped to most, hit end to read 
the whole range of commit logs into buffer, and then starting from the 
end, pageup one page at a time to get the merge chronology correct, and 
read all of Linus's very nicely summarized merge commits, telling me what 
trees were merged and listing the one-line title/summary for each one.

If I want to drill down, as I generally do for specific subsystems
(fs/btrfs, drm/radeon, various subsystems like power I've had bugs with 
in the past), it's a multi-level hierarchy and thus easy enough to go 
from say the drm merge to the radeon sub-merge and check individual 
commits at the comment and affected file levels (--stat).

If I want to drill down further, the commit ID is right there and I can 
git show <ID> to read the specific code.

Meanwhile, if the top-level merge commit says it's for example arm, I'll 
immediately move on to the next top-level merge commit, effectively 
skipping all those possibly hundreds of "boring and not interesting to 
me" individual arm commits, by very simply skipping to the next very 
nicely commented merge commit, with its one-liner list of individual 
commits.

The merge hierarchy, informative merge commit comments, and color-coded
--graph makes finding the merges so easy! That's the way git was 
/designed/ to work. =:^)


Unfortunately, gentoo is by policy trying to flatten all that multi-level-
hierarchy-for-a-reason into a single flat list of CVS/SVN-like strictly 
ordered parent-child relationship commits, destroying the whole rich 
hierarchy and all the information that git includes with it, using 
horrible rebase-pushes as an incredibly poor substitute for the very 
natural git-native merge hierarchy along with all its richness.


Now we're complaining about how flat/boring/uninformative all those 
atomic commits are, but it's not the atomic commits that are the problem, 
it's the fact that we're deliberately stripping out the merge commits and 
all the richness that comes with them, including the natural hierarchy 
and the ability to make those merge-commits as informative as they 
normally are in the kernel, with a short mention of the highlights and a 
quick list of the included one-liners.


If gentoo were doing git the way it was designed to work instead of 
trying to force it into the one-dimensional CVS mold, ago's 300-commit 
bore for anyone not interested in that subsystem, on gentoo commit after 
boring one-dimensional commit that's of less interest to me than the 
price of tea in China, would be in a single merge tree with the arch team 
in the one-liner, so I could immediately skip on to the next top-level 
merge.  Pageup to that merge, spotted quickly by the asterisk in the left 
column, the two lines merging to it, and the change in color in the left-
hand-line, see it's of no interested, and on to the next one, instead of 
having to go thru 300 boring one dimensional commits in case something 
I'm interested in squeezed in there somewhere.

So as I said, the problem isn't the atomic commits, it's gentoo's 
strongly recommended lack of merge hierarchy.  Now we're complaining 
about that and trying to kill the atomic commits, but they're not the 
problem, trying to use that new git nailgun as if it's the manual 
screwdriver of yesteryear is the problem.  If we don't fix that, we'll 
simply be trying to replace one small bit of the information we so 
mercilessly stripped out with those forced-to-one-dimension rebases, 
instead of deciding that stripping all that information out in the first 
place wasn't such a good idea after all and that the real solution is to 
simply stop trying to use that power nailgun as a manual screwdriver!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


[prev in list] [next in list] [prev in thread] [next in thread]