On Wed, Sep 4, 2013 at 6:59 PM, Junio C Hamano <gitster@xxxxxxxxx> 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.
At any rate, this preserves the ordering we desire, but feels like a
less than optimal process.
-John
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html