Re: [PATCH] Adding rebase merge strategy

On Mon, 1 Oct 2007 18:30:50 -0400, "Shawn O. Pearce" wrote:

`git pull -s <name>` takes any merge strategy that git-merge will
accept for its -s option.  There is also the config option of
pull.twohead that indicates what the default merge/pull strategy
should be for a two head merge.  Most people don't set this,
letting the code default to 'recursive'.

Ah, "pull.twohead". I don't think I ever would have guessed that. (And
I was just about to ask if there was a nice place to find all these
options, but then found it myself on my first guess with "man
git-config". Thanks everyone for writing that!).

But I have to agree with (was it Junio who said this?) doing a rebase
in a merge strategy doesn't make sense when conflicts come into play.

Sure. Rebase alone isn't useful as a complete merge strategy. But a
rebase strategy that simply fails in the face of a conflict,
(deferring to a subsequent merge strategy), could be very useful.

It gets confusing fast for the end-user as the conflict resolution
process is different than for a merge.  A long time ago I wrote a
git-merge-rebase strategy and gave up on it for basically the same
reason.  I posted it to the mailing list and I think Linus said
"Why?!".  That was the end of that thread as I wound up agreeing
with him.

Yes, I thought I recalled seeing a rebase strategy go by in the past,
but I had never gotten around to trying it out. I'll try to do better
on this try.

Multiple merge strategies can be given (and attempted).  A rebase
strategy could be attempted before recursive, and if the rebase
fails but the recursive succeeds then you get (roughly) what is
being described above by Carl.  But that still requires a rebase
merge strategy.  :-\

Yes, this sounds exactly like what I want. So, I put "rebase
recursive" in place as the value for the pull.twohead configuration?
An then make sure that the rebase strategy aborts as "failed" instead
of "conflicted and left for user to resolve"? I saw Junio talking
about return values up above in the thread but didn't pay attention to
details, (2 vs. 1 or something)?

Has anyone tried this rebase then recursive strategy yet? I'm
definitely interested in trying it out, as I think I'd
find it quite nice as a default for pull in my usage.

Though actually I'd like it even more if there was some way to mark a
commit as having been "published" and the rebase strategy would refuse
to rebase published commits. Maybe that's a per-branch
"last-published" reference? I think I'd even like git-push to update
the last-published reference for each pushed branch by default, but
then perhaps have an option to mark a particular remote so that
pushing to that remote doesn't count as publishing.

-Carl