Re: [PATCH 0/3] Reject non-ff pulls by default

> On Wed, Sep 4, 2013 at 6:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
> [snip]
> > When "git pull" stops because what was fetched in FETCH_HEAD does
> > not fast-forward, then what did _you_ do (and with the knowledge you
> > currently have, what would you do)?  In a single project, would you
> > choose to sometimes rebase and sometimes merge, and if so, what is
> > the choice depend on?  "When I am on these selected branches, I want
> > to merge, but on other branches I want to rebase?"
> 
> Our team isn't quite proficient enough yet to have a completely rebase
> workflow... though we might have less of a problem if we did.  So,
> several interesting points.  Most of the time, `git pull` would be a
> fast-forward merge.  We typically perform the merges of topic branches
> server-side--we have a build server who checks to make sure the result
> would be successful--and we just hit the big green button on the Merge
> button for the pull request (we use GitHub Enterprise at the moment).
> 
> However, nearly as often, we just merge the branch locally because
> someone on the team is doing some manual testing, and it's just
> convenient to finish the process on the command line.  What
> occasionally happens is that you merge the topic locally, but someone
> else has introduced a new commit to master.  We try to preserve the
> mainline ordering of commits, so `git pull` doing a merge underneath
> the hood is undesirable (it moves the newly introduced commit off to
> the side).  Rebasing your current master branch is not the answer
> either, because it picks up the commits introduced by the topic branch
> and rebases those to--at least with the -p option, and without it, the
> results are just as bad).  Instead, we want to unfold our work,
> fast-forward merge the upstream, and the replay our actions--namely
> remerge the topic branch.  It often ends up translating to this:
> 
>    $ git reset --hard HEAD~1
>    $ git merge --ff-only @{u}
>    $ git merge topic
>    $ git push
> 
> So what I really want isn't quite rebase.  I'm not sure any of the
> proposed solutions would work.  It'd be really nice to replay only the
> mainline commits, without affecting commits introduced from a topic
> branch.