On Mon, Mar 3, 2014 at 4:37 PM, Matthieu Moy
<Matthieu.Moy@xxxxxxxxxxxxxxx> wrote:
> Michael Haggerty <mhagger@xxxxxxxxxxxx> 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..
--
Duy
--
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