Re: [PATCH 2/3] rebase: accept -number as another way of saying HEAD~number
On 03/02/2014 04:55 PM, Matthieu Moy wrote: Eric Sunshine sunsh...@sunshineco.com writes: On Sun, Mar 2, 2014 at 3:53 AM, Eric Sunshine sunsh...@sunshineco.com wrote: On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote: This is rev-list style, where people can do git rev-list -3 in addition to git rev-list HEAD~3. A lot of commands are driven by the revision machinery and also accept this form. This addition to rebase is just for convenience. I'm seeing some pretty strange results with this. If I use -1, -2, or -3 then it rebases the expected commits, however, -4 gives me 9 commits, and -5 rebases 35 commits. Am I misunderstanding how this works? Nevermind. I wasn't paying attention to the fact that I was attempting to rebase merges. Your remark is actually interesting. Most (all?) Git commands taking -n as parameters act on n commits, regardless of merges. So, this commit creates an inconsistency between e.g. git log -3 (show last 3 commits) and git rebase -3 (rebase up to HEAD~3, but there may be more commits in case there are merges). I don't have a better proposal, but at least the inconsistancy should be documented (e.g. note that this is different from what other commands like 'git log' do when used with a -number option since ... in the manpage). This might be a reason that -NUM is a bad idea. 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. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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
Re: [PATCH 2/3] rebase: accept -number as another way of saying HEAD~number
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, 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/
--
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
Re: [PATCH 2/3] rebase: accept -number as another way of saying HEAD~number
On Mon, Mar 3, 2014 at 4:37 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
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).
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] rebase: accept -number as another way of saying HEAD~number
Duy Nguyen pclo...@gmail.com writes:
On Mon, Mar 3, 2014 at 4:37 PM, Matthieu Moy
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?
I don't think so. My use case is when I did a manual merge, so
@{upstream} is helpless or even not positionned. There is for sure an
accurate command (remember the branch I just merged and put it on the
command-line), but my fingers prefer typing quick and dirty commands and
hope I won't get too many trial and error cycles ;-).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
Re: [PATCH 2/3] rebase: accept -number as another way of saying HEAD~number
On Mon, Mar 03, 2014 at 10:37:11AM +0100, Matthieu Moy wrote:
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).
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
--
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
Re: [PATCH 2/3] rebase: accept -number as another way of saying HEAD~number
Duy Nguyen pclo...@gmail.com writes:
On Mon, Mar 3, 2014 at 4:37 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
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).
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
--
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
Re: [PATCH 2/3] rebase: accept -number as another way of saying HEAD~number
Michael Haggerty mhag...@alum.mit.edu writes: This might be a reason that -NUM is a bad idea. 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. That sounds like one possible way out; the opposite would be to enable mode that preserges merges when we see any. If rebase had a --first-parent mode that simply replays only the commits on the first parent chain, merging the same second and later parents without looking at their history when dealing with merge commits, and always used that mode unless --flatten-history was given, the world might have been a better place. We cannot go there in a single step, but we could plan such a backward incompatible migration if we wanted to. -- 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
Re: [PATCH 2/3] rebase: accept -number as another way of saying HEAD~number
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
Re: [PATCH 2/3] rebase: accept -number as another way of saying HEAD~number
Junio C Hamano gits...@pobox.com writes:
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?
The most common case is when @{upstream} is not positionned at all,
because I'm on a temporary branch on which I did not configure it. The
other case is when I did a manual merge of a branch other than upstream.
As I said in another message, there would probably be cleaner solutions,
but the trial and error one does not work that bad.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
Re: [PATCH 2/3] rebase: accept -number as another way of saying HEAD~number
On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote: This is rev-list style, where people can do git rev-list -3 in addition to git rev-list HEAD~3. A lot of commands are driven by the revision machinery and also accept this form. This addition to rebase is just for convenience. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- diff --git a/git-rebase.sh b/git-rebase.sh index 5f6732b..33face1 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -342,6 +346,11 @@ do esac shift done +if [ -n $NUM ] With the exception of one errant if [...], git-rebase.sh uniformly uses if test +then + test $# -gt 0 usage + set -- $@ HEAD~$NUM +fi test $# -gt 2 usage if test -n $cmd diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh index 6d94b1f..11db7ea 100755 --- a/t/t3400-rebase.sh +++ b/t/t3400-rebase.sh @@ -215,4 +215,10 @@ test_expect_success 'rebase commit with an ancient timestamp' ' grep author .* 34567 +0600$ actual ' +test_expect_success 'rebase -number' ' + git reset --hard + test_must_fail git rebase -2 HEAD^^ + git rebase -2 +' + test_done -- 1.9.0.40.gaa8c3ea -- 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
Re: [PATCH 2/3] rebase: accept -number as another way of saying HEAD~number
On Sun, Mar 2, 2014 at 3:37 PM, Eric Sunshine sunsh...@sunshineco.com wrote: On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote: This is rev-list style, where people can do git rev-list -3 in addition to git rev-list HEAD~3. A lot of commands are driven by the revision machinery and also accept this form. This addition to rebase is just for convenience. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- diff --git a/git-rebase.sh b/git-rebase.sh index 5f6732b..33face1 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -342,6 +346,11 @@ do esac shift done +if [ -n $NUM ] With the exception of one errant if [...], git-rebase.sh uniformly uses if test Besides that and three more if [...] in git-rebase--interactive.sh, git-rebase*.sh uses if test... only. Will reroll with a cleanup patch to make them all if test.. -- Duy -- 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
Re: [PATCH 2/3] rebase: accept -number as another way of saying HEAD~number
On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
This is rev-list style, where people can do git rev-list -3 in
addition to git rev-list HEAD~3. A lot of commands are driven by the
revision machinery and also accept this form. This addition to rebase
is just for convenience.
I'm seeing some pretty strange results with this. If I use -1, -2, or
-3 then it rebases the expected commits, however, -4 gives me 9
commits, and -5 rebases 35 commits. Am I misunderstanding how this
works?
I'm testing on a branch based on master with these three patches applied.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/git-rebase.txt | 3 +++
git-rebase.sh| 9 +
t/t3400-rebase.sh| 6 ++
3 files changed, 18 insertions(+)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 2a93c64..52c3561 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -223,6 +223,9 @@ As a special case, you may use A\...B as a shortcut for
the
merge base of A and B if there is exactly one merge base. You can
leave out at most one of A and B, in which case it defaults to HEAD.
+-number::
+ Specify upstream as HEAD~number.
+
upstream::
Upstream branch to compare against. May be any valid commit,
not just an existing branch name. Defaults to the configured
diff --git a/git-rebase.sh b/git-rebase.sh
index 5f6732b..33face1 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -43,6 +43,7 @@ continue! continue
abort! abort and check out the original branch
skip! skip current patch and continue
edit-todo! edit the todo list during an interactive rebase
+-NUM equivalent of HEAD~NUM
. git-sh-setup
. git-sh-i18n
@@ -335,6 +336,9 @@ do
--gpg-sign=*)
gpg_sign_opt=-S${1#--gpg-sign=}
;;
+ -NUM=*)
+ NUM=${1#-NUM=}
+ ;;
--)
shift
break
@@ -342,6 +346,11 @@ do
esac
shift
done
+if [ -n $NUM ]
+then
+ test $# -gt 0 usage
+ set -- $@ HEAD~$NUM
+fi
test $# -gt 2 usage
if test -n $cmd
diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh
index 6d94b1f..11db7ea 100755
--- a/t/t3400-rebase.sh
+++ b/t/t3400-rebase.sh
@@ -215,4 +215,10 @@ test_expect_success 'rebase commit with an ancient
timestamp' '
grep author .* 34567 +0600$ actual
'
+test_expect_success 'rebase -number' '
+ git reset --hard
+ test_must_fail git rebase -2 HEAD^^
+ git rebase -2
+'
+
test_done
--
1.9.0.40.gaa8c3ea
--
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
--
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
Re: [PATCH 2/3] rebase: accept -number as another way of saying HEAD~number
On Sun, Mar 2, 2014 at 3:53 AM, Eric Sunshine sunsh...@sunshineco.com wrote: On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote: This is rev-list style, where people can do git rev-list -3 in addition to git rev-list HEAD~3. A lot of commands are driven by the revision machinery and also accept this form. This addition to rebase is just for convenience. I'm seeing some pretty strange results with this. If I use -1, -2, or -3 then it rebases the expected commits, however, -4 gives me 9 commits, and -5 rebases 35 commits. Am I misunderstanding how this works? Nevermind. I wasn't paying attention to the fact that I was attempting to rebase merges. -- 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
Re: [PATCH 2/3] rebase: accept -number as another way of saying HEAD~number
Eric Sunshine sunsh...@sunshineco.com writes: On Sun, Mar 2, 2014 at 3:53 AM, Eric Sunshine sunsh...@sunshineco.com wrote: On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote: This is rev-list style, where people can do git rev-list -3 in addition to git rev-list HEAD~3. A lot of commands are driven by the revision machinery and also accept this form. This addition to rebase is just for convenience. I'm seeing some pretty strange results with this. If I use -1, -2, or -3 then it rebases the expected commits, however, -4 gives me 9 commits, and -5 rebases 35 commits. Am I misunderstanding how this works? Nevermind. I wasn't paying attention to the fact that I was attempting to rebase merges. Your remark is actually interesting. Most (all?) Git commands taking -n as parameters act on n commits, regardless of merges. So, this commit creates an inconsistency between e.g. git log -3 (show last 3 commits) and git rebase -3 (rebase up to HEAD~3, but there may be more commits in case there are merges). I don't have a better proposal, but at least the inconsistancy should be documented (e.g. note that this is different from what other commands like 'git log' do when used with a -number option since ... in the manpage). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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
[PATCH 2/3] rebase: accept -number as another way of saying HEAD~number
This is rev-list style, where people can do git rev-list -3 in
addition to git rev-list HEAD~3. A lot of commands are driven by the
revision machinery and also accept this form. This addition to rebase
is just for convenience.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/git-rebase.txt | 3 +++
git-rebase.sh| 9 +
t/t3400-rebase.sh| 6 ++
3 files changed, 18 insertions(+)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 2a93c64..52c3561 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -223,6 +223,9 @@ As a special case, you may use A\...B as a shortcut for
the
merge base of A and B if there is exactly one merge base. You can
leave out at most one of A and B, in which case it defaults to HEAD.
+-number::
+ Specify upstream as HEAD~number.
+
upstream::
Upstream branch to compare against. May be any valid commit,
not just an existing branch name. Defaults to the configured
diff --git a/git-rebase.sh b/git-rebase.sh
index 5f6732b..33face1 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -43,6 +43,7 @@ continue! continue
abort! abort and check out the original branch
skip! skip current patch and continue
edit-todo! edit the todo list during an interactive rebase
+-NUM equivalent of HEAD~NUM
. git-sh-setup
. git-sh-i18n
@@ -335,6 +336,9 @@ do
--gpg-sign=*)
gpg_sign_opt=-S${1#--gpg-sign=}
;;
+ -NUM=*)
+ NUM=${1#-NUM=}
+ ;;
--)
shift
break
@@ -342,6 +346,11 @@ do
esac
shift
done
+if [ -n $NUM ]
+then
+ test $# -gt 0 usage
+ set -- $@ HEAD~$NUM
+fi
test $# -gt 2 usage
if test -n $cmd
diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh
index 6d94b1f..11db7ea 100755
--- a/t/t3400-rebase.sh
+++ b/t/t3400-rebase.sh
@@ -215,4 +215,10 @@ test_expect_success 'rebase commit with an ancient
timestamp' '
grep author .* 34567 +0600$ actual
'
+test_expect_success 'rebase -number' '
+ git reset --hard
+ test_must_fail git rebase -2 HEAD^^
+ git rebase -2
+'
+
test_done
--
1.9.0.40.gaa8c3ea
--
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
