On Thu, Sep 05, 2013 at 07:01:03AM -0400, John Szakmeister wrote:
> 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.
Does "git rebase --preserve-merges" do what you want here?
--
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