Re: [boost] [git] Pushing commit(s) after pulling

Subject: Re: [boost] [git] Pushing commit(s) after pulling
From: Vladimir Prus (ghost_at_[hidden])
Date: 2014-08-20 00:09:18

On 08/20/2014 05:18 AM, Gavin Lambert wrote:
> 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.

Yep, I normally merge pull requests by hand, using "git fetch" + "git cherry-pick" of FETCH_HEAD - optionally squashing.

> 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.

You are correct. Was not a problem in practice for me though - the branches being pull-requested had temporary-sounding names.

- Volodya