This post is regarding this discussion in the mailing list, to
which I currently can't post:
http://forum.dlang.org/post/20131115141721.gr30...@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.
