[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost
Subject:    Re: [boost] [git] Pushing commit(s) after pulling
From:       Vladimir Prus <ghost () cs ! msu ! su>
Date:       2014-08-20 4:09:18
Message-ID: lt171c$1he$1 () ger ! gmane ! org
[Download RAW message or body]

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


[prev in list] [next in list] [prev in thread] [next in thread]