Michael Haggerty [off-list ref] 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, 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.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
On Mon, Mar 3, 2014 at 4:37 PM, Matthieu Moy
[off-list ref] wrote:
Michael Haggerty [off-list ref] writes:
quoted
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
On Mon, Mar 03, 2014 at 10:37:11AM +0100, Matthieu Moy wrote:
Michael Haggerty [off-list ref] writes:
quoted
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).
Yeah, I agree with this. I think "-NUM" is only useful for linear
string-of-pearls history. With merges, it either means:
- linearize history (a la git-log), go back NUM commits, and treat the
result as the upstream. This is useless, because it's difficult to
predict where you're going to end up. Using explicit "~" and "^"
relative-commit operators to specify the upstream is more flexible
if you really want to do this (but I don't know why you would).
- do not use an UNINTERESTING upstream as the cutoff, but instead
try to rebase exactly NUM commits. In the face of non-linear
history, I'm not even sure what this would mean, or how we would
implement it.
Neither of those is useful, so I don't think erroring out on them is a
bad thing. And by erroring out (rather than documenting some weird and
useless behavior), we don't have to worry about backwards compatibility
if we later _do_ come up with a useful behavior (the best I can think of
is that "--first-parent -3" might have a use, but I think that should
already be covered, as the results of --first-parent are by-definition
linear).
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.
I do the same thing.
-Peff