cbergstrom posted on Sun, 08 May 2016 13:44:43 +0800 as excerpted: > Don't be crazy - I know many developer groups which dislike merge > commits. That nonlinear work flow is just a mess long term.
Said by someone who apparently can't figure out reasonable quote then reply-in-context, or even appropriate quote nesting, either. <shrug> > Original Message > From: Michał Górny Sent: Sunday, May 8, 2016 13:09 To: Patrice Clement > Reply To: gentoo-dev@lists.gentoo.org Cc: gentoo-dev@lists.gentoo.org > Subject: Re: [gentoo-dev] On banning merge commits > > On Sun, 8 May 2016 01:52:22 +0200 Patrice Clement <monsie...@gentoo.org> > wrote: > >> Hi gents >> >> After yet another discussion about git in the #gentoo-dev channel >> tonight, the topic of merge commits came up for the umpteenth time. >> >> We all seem to agree merge commits are really bad design, add clutter >> to the log graph after a while and should be banned altogether from >> reaching the central repository. >> >> As of now, no policy is in place yet to keep developers from pushing >> merge commits. >> >> What is the correct course of action? I would very much like it to be >> worded in a document (GLEP and/or Wiki page) so that confusion is >> avoided and we all are on the same page on this topic. > > You start by accepting my retirement. Agreed with mgorny here. In fact, I'd suggest banning *non-*merge push-commits. It's forcing the rebases that is really bad design, removing useful information from the log graph, etc. The reason gentoo's git logs are such a mess now is that they're mostly flat. Initial commits are normally one atomic issue per initial commit, good, but then instead of naturally grouping them by subject with a well commented merge commit, as is done for example with the mainline kernel tree, they're unnaturally forced into a flat list by rebases instead of the more natural merges, horribly *bad*! Of course that loses all the rich information that the merges carry, including, when merges are done right, grouping individual atomic commits by general task/project, and appropriate merge comments outlining what was actually merged. With the kernel I can git log --graph ORIG_HEAD.. and by default search only for merges into the mainline/lefthand master branch. That gives me a very good overview of what subsystems were merged, and for the ones that interest me, I can read the merge commit comment and have a good idea what was merged from that subsystem. For the ones that are more interesting, I can drill down into the merge and read individual commit comments. If even that isn't enough, I can easily git show <commit> using the commit ID from the log, and get the full diff. Try doing that with gentoo. It doesn't work because everything's flat; there's too few merge commits. For instance, I've no interested in arm, and with the kernel git log, I can skip the majority of arm-affecting- only commits by just skipping the merge commits as soon as I see it's from the arm tree, while with the gentoo git log, all those arm stabilizations appear as hundreds of individual flat commits on the main branch, instead of a small handful of merge-commits, with merge-commit comments such as "arm stabilizations for app-foo/bar and deps". So on gentoo, what I end up doing instead is seeing what packages want to update, and only searching the git log for the interesting ones. Works well enough for that, but I've effectively no overview of what's going on in general as I do for the kernel tree, as I miss all the interesting commits that didn't happen to show up as package update candidates spit out by portage, even in areas I'd otherwise track rather heavily, like kde, where I track the kde overlay git log, but miss the gentoo repo side due to the problems created by lack of appropriate merge commits as explained above. Or to put it a different way, if we're not going to use git's rich distributed branch development and tracking, forcing everything to single chain on the main tree, why did we bother switching to git in the first place? That was available on cvs, or if we wanted more features, subversion, etc. -- 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
