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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]