Matthieu Moy <matthieu....@grenoble-inp.fr> writes:
> Michael Haggerty <mhag...@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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
