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
Attachment:
pgpxzQ0j2bvDq.pgp
Description: PGP signature
