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

[Clemens Buchacher <drizzd@aon.at>]

On Sun, Jan 08, 2012 at 02:58:42PM -0800, Junio C Hamano wrote:
> 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}.