This is what the recent commit history looks like:
Does anyone else miss the days when all commits were rebased? I find that the super-non-linear history makes it much more difficult to figure out what has changed between two points, or to pinpoint the cause of a regression.
It’s too bad github’s otherwise awesome pull request functionality doesn’t provide the option of rebasing rather than merging.
That’s actually the result of using Github’s Merge button. So it would create another commit every time you click on the merge button.
In this case those branches are public, so it is a Bad Thing to rebase them on master prior to the merge because all the sha1s change. You should only rebase private branches, merge to local master (after a pull --rebase) then push to upstream master. (to get linear history).
I think that makes sense.
Best resource about this subject: Pro Git.
There are two parties to a patch or a pull request: in git parlance, the author and the committer. You are talking about the author side of the process, which is often debated, but not what I meant to discuss right now. I’m talking about what the Rails core committers do with submitted patches and pull requests. Prior to the existence of the “Merge” button on github, Rails committers would routinely rebase submitted patches onto master. This leads to a nice, clean, linear history.
The “Merge” button, on the other hand, does not do rebase. In fact, it forces a merge commit even if the merge otherwise would have been a fast-forward. This leads to an extremely cluttered history:
I’m proposing we should keep doing things the previous way (i.e., not using the “Merge” button) until github offers an option to rebase when accepting a pull request.
To tell you the truth, I hate the fact that Github always create a commit that says “merging” stuff. What I’d rather would like to have is that Github would try to fast-forward merge first, then fallback to three-way-merge if it’s failed.
Yes, that is annoying. Perhaps you should refer the issue to github.
I don't know if this will help but git log --no-merges will hide the merge commits. If you want to pinpoint a regression why not use git bisect?
Chris