Markus Roberts wrote:
> P.S. On a related subject: I'm close to advocating a total ban on
> merge commits as opposed to rebasing / cherry-picking.  Merge
> commits in git are. IMHO, seriously broken (a significant fraction
> of the tools "ignore" them and many of the ones that don't simply
> act up when they encounter one).
>
> Can anyone give a cogent reason why they are a good thing, or show
> me the error of my ways?

Well, if you use rebasing and cherry-picking you are creating new
commits rather than applying the existing commits as a merge would do.
This removess much of git's ability to track which commits have been
merged and which have not.

In an ideal world, you would be able to use git 0.25.x...master which
would show you commits that only in either 0.25.x or master but noth
both, which would illistrace things that needed merged.  (Note that
three dots is different than two here.)

Merges are preferable to cherry-picking¹ due to the ability it adds
for git to track.  And rebasing is something that should only be used
on branches that are not public, generally.  This might not be as true
for a testing branch, but it definitely holds for master and other
stable branches -- those should _never_ be rebased. :)

Also worth a read (if you haven't stumbled across it already is the
"maintain-git" howto², which describes in some detail how git.git is
managed.  As git.git generally has a large number of topics in flight
it may well serve as a good guide.  The 'pu' and 'next' branches in
git.git sound a lot like what you're aiming for with a 'testing'
branch.

All that said, you don't want end users pushing merge commits to you,
as that is nothing but noise and confusion I believe.  Folks
submitting patches or asking you to pull should provide a branch
rebased against whatever topic branch they want their work applied on.
If that's what you mean by banning merge commits, then that sounds
good. :)

¹ 
http://kernel.org/pub/software/scm/git/docs/gitworkflows.html#_managing_branches
² http://kernel.org/pub/software/scm/git/docs/howto/maintain-git.txt

(I should of course note that I don't have any direct experience
managing a large git repository, so what I write is based on my
reading of the documentation and the git list.  So keep that in mind
when weighing my opinions. ;)

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hardware:  the parts of a computer that can be kicked.
    -- Jeff Pesis

Attachment: pgp0RfTHke6lK.pgp
Description: PGP signature

Reply via email to