On Mon, Oct 01, 2007 at 03:17:28PM -0700, Carl Worth wrote:
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?
Surely the job of a merge strategy is to take two heads and produce a
single merge commit?
If it's worth automating the steps you describe above, I think it'd be
better to choose an entirely different name for the command.
--b.