From: J. Bruce Fields <bfields@fieldses.org>
Date: Mon, 01 Oct 2007 23:09:36 GMT
Subject: Re: [PATCH] Adding rebase merge strategy
Message-ID: <20071001230936.GA5556@fieldses.org>
In-Reply-To: <87ejgescnb.wl%cworth@cworth.org>

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.