Re: [PATCH 2/3] rebase: accept -<number> as another way of saying HEAD~<number>

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 3, 2014, 21:48 UTC
Message-ID: <xmqqha7fnebn.fsf@gitster.dls.corp.google.com>
In-Reply-To: <vpq7g8bfws8.fsf@anie.imag.fr>

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

Show 13 quoted lines

> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> Or perhaps "-NUM" should fail with an error message if any of the last
>> NUM commits are merges.  In that restricted scenario (which probably
>> accounts for 99% of rebases), "-NUM" is equivalent to "HEAD~NUM".
>
> Makes sense to me. So, -NUM would actually mean "rebase the last NUM
> commits" (as well as being an alias for HEAD~NUM), but would fail when
> it does not make sense (with an error message explaining the situation
> and pointing the user to HEAD~N if this is what he wanted).
>
> This would actually be a feature for me: I often want to rebase "recent
> enough" history, and when my @{upstream} isn't well positionned,...

Could you elaborate on this a bit? What does "isn't well positioned" mean? Do you mean "the upstream has advanced but there is no reason for my topic to build on that---I'd rather want to make sure I can view 'diff @{1} HEAD' and understand what my changes before the rebase was"? That is, what you really want is

	git rebase -i --onto $(git merge-base @{upstream} HEAD) @{upstream}

but that is too long to type?

If it is very common (and I suspect it is), we may want to support such a short-hand---the above does not make any sense without '-i', but I would say with '-i' you do not want to reBASE on an updated base most of the time. "git rebase -i @{upstream}...HEAD" or something?