[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]