On Mon, 1 Oct 2007 18:30:50 -0400, "Shawn O. Pearce" wrote:
quoted text
> `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!).

quoted text
> 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.

quoted text
> 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.

quoted text
> 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