Re: [PATCH] rebase --fix: interactive fixup mode

From: Clemens Buchacher <drizzd@aon.at>
Date: Jan 9, 2012, 20:33 UTC
Message-ID: <20120109203357.GC25269@ecki>
In-Reply-To: <7vfwfpg5st.fsf@alter.siamese.dyndns.org>

On Sun, Jan 08, 2012 at 02:58:42PM -0800, Junio C Hamano wrote:

Show 14 quoted lines

> Clemens Buchacher <drizzd@aon.at> writes:
> >
> > In order to determine a suitable range automatically, it is a reasonable
> > heuristic to rebase onto the most recent merge commit.
> 
> I understand the problem you are trying to solve, but I am not sure if
> this is a good idea from the UI point of view for two reasons.
> 
>  - "We want to limit the extent of the operation to commits since the last
>    merge" is by itself a reasonable thing to ask, and I do not think it
>    should be limited to "rebase". If we had an extended SHA-1 syntax to
>    express it, for example, you may want to say "I want to see what I did
>    since the last merge" and run "git log $last_merge_before_HEAD..".
>    Perhaps HEAD~{merge} or something?

Ok, sounds reasonable.

I am not sure what to do if the history has no merges, though. If it's just rev-parse HEAD~{merge} I suppose I could return nothing, or an error. But what about the HEAD~{merge}..HEAD range? I think it would be useful if that were not an error but the entire history.

>  - If your "rebase --fix" is to "fix" things, what is "rebase -i" about?

I would have suggested this to be the default behavior for rebase -i without an <upstream> argument, but unfortunately we already handle this case using @{upstream}.