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 <a...@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
