Boost logo

Boost :

Subject: Re: [boost] [git] Pushing commit(s) after pulling
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-08-19 21:18:22


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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk