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