[m-dev.] Discussion about git merge vs rebase on GHC mailing lists.

[Ben Schmidt]

On 25/02/13 11:03 PM, Ian MacLarty wrote:
 > On Mon, Feb 25, 2013 at 10:23 PM, Peter Ross <peter at emailross.com> wrote:
 >> On 24 February 2013 11:01, Paul Bone <paul at bone.id.au> wrote:
 >>>
 >>> A while ago we had a discussion about git merge vs git rebase.  There has
 >>> been a similar discussion on the GHC mailing lists that people might find
 >>> interesting.
 >>>
 >> I think the biggest issue with git is the learning curve.  It is a
 >> more complex system than subversion or cvs.  The complexity means you
 >> can do some cool things, but it does mean it takes awhile to learn
 >> what how it works.
 >>
 >> I found this blog post quite instructive
 >>
 >> https://sandofsky.com/blog/git-workflow.html
 >
 > I only "clicked" with git when I read this:
 > http://eagain.net/articles/git-for-computer-scientists/.  The
 > underlying data structures are quite simple and elegant, unlike the
 > user interface.

So sad to see another great project choose Git over Mercurial.

The good news is that Mercurial has an amazing plugin system, so you can
actually losslessly interact with Git repositories by installing the
hg-git plugin. Hg bookmarks correspond to Git branches.

If you find the Git UI a bit nasty (as I do), consider learning
Mercurial which is much more friendly (and significantly safer for your
data, too, IMHO).

As far as rebasing and merging goes, my preference is for merging,
because you maintain the history of the changes, and have less work to
do before you push.

E.g. if you ensure every changeset builds as you commit, but then
rebase, you have to check every changeset again, and possibly do a stack
of history rewriting to fix things up. If you merge, you simply have to
check the merge changeset.

Another example: say you make a systematic but hard-to-detect change
throughout the codebase (i.e. it won't generate compiler warnings or
anything if it isn't made in some file, but may cause runtime problems).
Say somebody else adds a file in parallel which should also have had the
change. If you rebase, it's easy to miss the change because it's hard to
detect. Some time later, you pick up a bug at runtime and look through
history to investigate; it's hard to see what happened, because you've
rewritten history. It looks like the file was added and then you made
your change, so it's logical to assume your change applied to the
previously added file. If you merge, you still may miss the change at
merge-time, but when you look through history it's clear that two
changes have happened in parallel by independent developers, and the
merge changeset is the one that obviously stands out as where something
could have gone wrong, i.e. a developer unfamiliar with the other's work
didn't understand the full consequences and what it necessitated for the
merge.

To facilitate Hg-git interoperability, though, I suggest not using Git's
octopus merge feature. Hg only merges two branches at a time. It's not
an onerous restriction (and IMHO is actually quite a smart idea--good
development practice), and it assists people like me who vastly prefer
Hg, believing it to be far superior to Git, particularly in the UI
department, and will be accessing the Git repo using Hg.

Smiles,

Ben.