Re: [PATCH 2/3] rebase: accept -number as another way of saying HEAD~number

2014-03-03 Thread Michael Haggerty
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

2014-03-03 Thread Matthieu Moy
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

2014-03-03 Thread Duy Nguyen
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

2014-03-03 Thread Matthieu Moy
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

2014-03-03 Thread Jeff King
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

2014-03-03 Thread David Kastrup
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

2014-03-03 Thread Junio C Hamano
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

2014-03-03 Thread Junio C Hamano
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

2014-03-03 Thread Matthieu Moy
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

2014-03-02 Thread Eric Sunshine
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

2014-03-02 Thread Duy Nguyen
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

2014-03-02 Thread Eric Sunshine
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

2014-03-02 Thread Eric Sunshine
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

2014-03-02 Thread Matthieu Moy
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