On Mon, 1 Oct 2007 23:41:56 +0200, "Tom Clarke" wrote:
> Thanks for the ample feedback, you raise a number of interesting
> issues. I am wondering now if making rebase a merge strategy is really
> a good idea. Rebasing is not merging, a difference that could perhaps
> be overlooked in the no-conflict scenario, but as you point out, is
> glaringly obvious as soon as you have conflicts.
What I think I've always wanted is something like the following
behavior for "git pull":
* Fast forward if possible
* Otherwise, rebase, but only if there are no conflicts at all
* Otherwise, do the merge as normal, (leave conflict markers in
place allowing the user to fix them up and then commit).
Would it be straightforward to turn your rebase merge strategy into
something like the above? And if so, would that address the primary
concerns that Junio raised?
-Carl
Attachment:
pgptQxVXtiKWM.pgp
Description: PGP signature
