On 20/08/2014 02:53, Vladimir Prus wrote:
Thanks for writing this down in detail! It's indeed a matter of preference, although:
- For Boost.Build specifically, I prefer to avoid merge commits as much as possible. - In most cases of a single commit, or a few unrelated commits, using "git pull" and creating merge commits results in rather noisy and unclear history. I'd imagine maintainers of other components might prefer to avoid that - although it's up to them, of course.
One case where it's a bit trickier to define the "right thing" is with pull requests. The simplest thing to do (especially if you're using the GitHub UI) is to simply merge the pull request directly. Obviously this does create a merge commit and you'll see a fork in the revision graph as in my first diagram. Often the pull request is created in isolation (especially if the user was using the GitHub editing UI directly) and so the maintainer could reasonably safely do a rebased or squashed pull on this branch to keep the core history "clean". This can be especially tempting if there were multiple commits to the PR branch during its lifetime to correct various issues raised by the maintainer -- then a squashed merge would produce a single "pristine" commit without all of the fumbling. The downside of the latter is that the history will no longer show which PR branch it came from (that's the part you're cleaning) -- and if the user didn't create it as a throwaway but is using it in one of their own branches (which is likely if they're using git themselves for their own software) then the former will just work nicely for them while the latter will create a conflict that forces them to rebase anything built on top of it.