On Sun, Jan 08, 2012 at 02:58:42PM -0800, Junio C Hamano wrote:
> Clemens Buchacher <drizzd@xxxxxx> 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}.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html