Please don't rebase / ff the git master branches

[Vladimir Panteleev]

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.