Please don't rebase / ff the git master branches

[qznc]

On Friday, 15 November 2013 at 22:36:14 UTC, Vladimir Panteleev
wrote:
> This post is regarding this discussion in the mailing list, to 
> which I currently can't post:
>
> http://forum.dlang.org/post/20131115141721.GR30523@llucax.com.ar
>
> There appears to be an unanimous opinion that GitHub should 
> allow merging pull requests by rebasing them onto master, and 
> fast-forwarding the branch to the last commit in the pull. IMO, 
> this is a bad idea!
>
> Currently, the merge commits provide important information: 
> which commits belong in which pull request, who merged the pull 
> request and when. I realize that merges visually clutter the 
> history in most git clients, however IMO the solution is not to 
> drop that information on the floor, but rather improve the 
> clients to present the history better.
>
> As I understood, it has also been suggested to instead rewrite 
> the commits in the pull request to include new information 
> (changing the commit's "committer" field). This is also bad, 
> because it will change the commit hash - and then, once the 
> pull is merged, suddenly the pull author's branch contains 
> different (though similar) commits than what's in master. If 
> someone were to attempt to merge the two, what used to be a 
> fast-forward will become a confusing mess.
>
> For an example of what the merge commits are useful for: I've 
> begun sketching a tool to automatically bisect D's history. 
> And, I don't mean DMD's history: I mean the history of D + 
> Phobos + Druntime. Since changes are often done to two or three 
> projects simultaneously, and one won't work without the other, 
> it is often difficult to run a git bisect on just one project, 
> as it will break sooner or later in the repo's history, as the 
> other D components become incompatible. While you can't really 
> sensibly merge three DAGs chronologically, it's easy to merge 
> three sorted lists (three linear histories). Git repositories 
> do not have linear histories, but the pull request merge 
> history does! Thus, it's practical only if you consider pull 
> request merges.

Yay, another war about git workflows. :)

It is sad that D history cannot be nicely tracked, because it is
split into three repositories without git having a clue about
dependencies between them.

At work we have a C compiler frontend [0] and a backend [1] in
different repos. The frontend includes the backend as a git
submodule. Therefore the frontend always uses a specific revision
of the backend. Bisecting is trivial now. Faulty commits to the
backend cannot not break the frontend, because it still points to
a previous revision.

[0] http://pp.info.uni-karlsruhe.de/git/cparser/
[1] http://pp.info.uni-karlsruhe.de/git/libFirm/