From: David Kastrup <dak@gnu.org>
Date: Mon, 03 Mar 2014 10:11:30 GMT
Subject: Re: [PATCH 2/3] rebase: accept -<number> as another way of saying HEAD~<number>
Message-ID: <87y50rlhgt.fsf@fencepost.gnu.org>
In-Reply-To: <CACsJy8CPhTQxpnY70PxD9zFSipaJCTQPBsmReD8E9tmEgsvTRg@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

> On Mon, Mar 3, 2014 at 4:37 PM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> 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).
>
> Agreed, but..
>
>> This would actually be a feature for me: I often want to rebase "recent
>> enough" history, and when my @{upstream} isn't well positionned, I
>> randomly type HEAD~N without remembering what N should be. When N is too
>> small, the rebase doesn't reach the interesting commit, and when N is
>> too big, it reaches a merge commit and I get a bunch of commits I'm not
>> allowed to edit in my todo-list. Then I have to abort the commit
>> manually. With -N failing on merge commits, the rebase would abort
>> itself automatically.
>
> would "git rebase -i --fork-point" be what you need instead? It's a
> new thing, but may be what we actually should use, not this -NUM..

-0 might be a good mnemonic for --fork-point, though.

Of course, when using --preserve-merges explicitly it would appear that
-NUM should not error out.

-- 
David Kastrup