git rebase -i

Hi,

  I often do   'git rebase -i HEAD~10'  to rebase.  Since afaics it
doesn't matter if you go back 'too far' I just always use HEAD~10 even
if it's just for the last or so commit.

  Would there be any objections to making  'git rebase -i' default to
HEAD~10  or maybe 16 or 20.  Having sensible defaults for commands
helps a bit with making it easier to use.

John

El 19/2/2009, a las 10:21, John Tapsell escribió:

Hi,

 I often do   'git rebase -i HEAD~10'  to rebase.  Since afaics it
doesn't matter if you go back 'too far' I just always use HEAD~10 even
if it's just for the last or so commit.

 Would there be any objections to making  'git rebase -i' default to
HEAD~10  or maybe 16 or 20.

Sounds awfully arbitrary and counter-intuitive to me.

Take a sample of Git users who know what "git rebase" does and ask  
them what they intuitively think "git rebase -i" without any  
additional arguments should do; I'd be _extremely_ surprised if they  
answered that it should default to HEAD~10, HEAD~16, HEAD~20, or  
HEAD~N for any N.

(I could tell you what my intuition tells me, but I don't think it's  
very interesting.)

Cheers,
Wincent

2009/2/19 Wincent Colaiuta [off-list ref]:

El 19/2/2009, a las 10:21, John Tapsell escribió:

quoted

Hi,

 I often do   'git rebase -i HEAD~10'  to rebase.  Since afaics it
doesn't matter if you go back 'too far' I just always use HEAD~10 even
if it's just for the last or so commit.

 Would there be any objections to making  'git rebase -i' default to
HEAD~10  or maybe 16 or 20.

Sounds awfully arbitrary and counter-intuitive to me.

Take a sample of Git users who know what "git rebase" does and ask them what
they intuitively think "git rebase -i" without any additional arguments
should do; I'd be _extremely_ surprised if they answered that it should
default to HEAD~10, HEAD~16, HEAD~20, or HEAD~N for any N.

(I could tell you what my intuition tells me, but I don't think it's very
interesting.)

It doesn't really matter if the user manages to guess what the number
N is, just that it's "recent commits".

If a sample of git users would expect "git rebase -i" to let you
rebase the last few commits, then it doesn't really matter all that
much what N is.  10 seems a reasonable default as any.

John

El 19/2/2009, a las 10:55, John Tapsell escribió:

2009/2/19 Wincent Colaiuta [off-list ref]:

quoted

El 19/2/2009, a las 10:21, John Tapsell escribió:

quoted

Hi,

I often do   'git rebase -i HEAD~10'  to rebase.  Since afaics it
doesn't matter if you go back 'too far' I just always use HEAD~10  
even
if it's just for the last or so commit.

Would there be any objections to making  'git rebase -i' default to
HEAD~10  or maybe 16 or 20.

Sounds awfully arbitrary and counter-intuitive to me.

Take a sample of Git users who know what "git rebase" does and ask  
them what
they intuitively think "git rebase -i" without any additional  
arguments
should do; I'd be _extremely_ surprised if they answered that it  
should
default to HEAD~10, HEAD~16, HEAD~20, or HEAD~N for any N.

(I could tell you what my intuition tells me, but I don't think  
it's very
interesting.)

It doesn't really matter if the user manages to guess what the number
N is, just that it's "recent commits".

If a sample of git users would expect "git rebase -i" to let you
rebase the last few commits, then it doesn't really matter all that
much what N is.  10 seems a reasonable default as any.

That's exactly the problem. Most git users aren't going to expect "git  
rebase -i" to let you "rebase the last few commits".

Rebase is mostly used, talked about, and conceptualized in terms of  
rebasing onto other _branches_.

Cheers,
Wincent

On 19 feb 2009, at 09:21, John Tapsell wrote:

 Would there be any objections to making  'git rebase -i' default to
HEAD~10  or maybe 16 or 20.  Having sensible defaults for commands
helps a bit with making it easier to use.

I'd prefer something a bit less arbitrary, like using the tracked head
for a tracking branch.

John Tapsell wrote:

  I often do   'git rebase -i HEAD~10'  to rebase.  Since afaics it
doesn't matter if you go back 'too far' I just always use HEAD~10 even
if it's just for the last or so commit.

It makes a *huge* difference if any of those last N commits is a merge.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

2009/2/19 Thomas Rast [off-list ref]:

John Tapsell wrote:

quoted

  I often do   'git rebase -i HEAD~10'  to rebase.  Since afaics it
doesn't matter if you go back 'too far' I just always use HEAD~10 even
if it's just for the last or so commit.

It makes a *huge* difference if any of those last N commits is a merge.

Lots of good points.  I'll leave this idea for now then :-)

On Thu, Feb 19, 2009 at 09:21:49AM +0000, John Tapsell wrote:

  I often do   'git rebase -i HEAD~10'  to rebase.  Since afaics it
doesn't matter if you go back 'too far' I just always use HEAD~10 even
if it's just for the last or so commit.

Here are some reasons not to go back too far:

  1. The commits are displayed in order, so the ones that are
     interesting to the user are at the bottom. And HEAD~10 may display
     more than 10 commits in the face of non-linear history.

  2. rebase -i does not preserve merges by default. Which means that if
     HEAD~10 is not a linear history, then you are flattening the graph
     structure.

  Would there be any objections to making  'git rebase -i' default to
HEAD~10  or maybe 16 or 20.  Having sensible defaults for commands
helps a bit with making it easier to use.

If you wanted to do something like this, a much more sensible cutoff
would be the location of an upstream tracking branch (e.g., as defined
by branch.*.rebase). Then you are literally asking for commits which
have not been published in your upstream, which means it is OK to
rewrite history (assuming they were not published elsewhere).

-Peff

On Thu, Feb 19, 2009 at 10:59:15AM +0100, Wincent Colaiuta wrote:

quoted

If a sample of git users would expect "git rebase -i" to let you
rebase the last few commits, then it doesn't really matter all that
much what N is.  10 seems a reasonable default as any.

That's exactly the problem. Most git users aren't going to expect "git  
rebase -i" to let you "rebase the last few commits".

Rebase is mostly used, talked about, and conceptualized in terms of  
rebasing onto other _branches_.

Actually, I don't think that's true anymore with "rebase -i"; it is
probably most convenient way in core git to rewrite the history of a
patchset. E.g., a core part of my workflow as a contributor is:

  $ git checkout -b jk/topic origin
  $ while true; do hack hack hack; commit commit commit; done
  $ git rebase -i origin

which gives me a list of everything on the topic, ready to be
reordered, squashed, or edited as appropriate.

-Peff

El 19/2/2009, a las 11:11, Jeff King escribió:

On Thu, Feb 19, 2009 at 10:59:15AM +0100, Wincent Colaiuta wrote:

quoted

quoted

If a sample of git users would expect "git rebase -i" to let you
rebase the last few commits, then it doesn't really matter all that
much what N is.  10 seems a reasonable default as any.

That's exactly the problem. Most git users aren't going to expect  
"git
rebase -i" to let you "rebase the last few commits".

Rebase is mostly used, talked about, and conceptualized in terms of
rebasing onto other _branches_.

Actually, I don't think that's true anymore with "rebase -i"; it is
probably most convenient way in core git to rewrite the history of a
patchset. E.g., a core part of my workflow as a contributor is:

 $ git checkout -b jk/topic origin
 $ while true; do hack hack hack; commit commit commit; done
 $ git rebase -i origin

which gives me a list of everything on the topic, ready to be
reordered, squashed, or edited as appropriate.

Yes, I do the same. But notice that you did "git rebase -i -- 
 >>>origin<<<---". Seems to me you are definitely _thinking_ in terms  
of your topic _branch_ and not in terms of "the last few commits".

Cheers,
Wincent

On Thu, Feb 19, 2009 at 11:15:51AM +0100, Wincent Colaiuta wrote:

quoted

Actually, I don't think that's true anymore with "rebase -i"; it is
probably most convenient way in core git to rewrite the history of a
patchset. E.g., a core part of my workflow as a contributor is:

 $ git checkout -b jk/topic origin
 $ while true; do hack hack hack; commit commit commit; done
 $ git rebase -i origin

which gives me a list of everything on the topic, ready to be
reordered, squashed, or edited as appropriate.

Yes, I do the same. But notice that you did "git rebase -i -- 

quoted

quoted

quoted

origin<<<---". Seems to me you are definitely _thinking_ in terms of 

your topic _branch_ and not in terms of "the last few commits".

Perhaps. I think of it as "the set of commits not yet published"
(since I publish only by sending patches to Junio, and he is my origin)
and nothing to do with the topic branch itself.

But we are just quibbling over minor terminology. I think we both agree
that HEAD~10 is silly and abitrary.

-Peff

On Thu, Feb 19, 2009 at 05:20:53AM -0500, Jeff King wrote:

quoted

Yes, I do the same. But notice that you did "git rebase -i -- 

quoted

quoted

quoted

origin<<<---". Seems to me you are definitely _thinking_ in terms of 

your topic _branch_ and not in terms of "the last few commits".

Perhaps. I think of it as "the set of commits not yet published"
(since I publish only by sending patches to Junio, and he is my origin)
and nothing to do with the topic branch itself.

Indeed, I bet most people who use this workflow think of git rebase -i
origin or "git rebase -i HEAD^^^^" (where I normally figure out how
many commits I need to go back and type the right number of carets) as
a magic command that does what we want, without necessarily thinking
about why it works the way that it does.

I can guarantee that most of the time I don't think "hmm, so I'm going
to be rebasing my topic branch onto origin so I can make some
changes."  Nope, it's, "I'm going to futz with the commits to get them
just right".

   	     	 	    	     - Ted

On Thu, Feb 19, 2009 at 4:21 AM, John Tapsell [off-list ref] wrote:

Hi,

 I often do   'git rebase -i HEAD~10'  to rebase.  Since afaics it
doesn't matter if you go back 'too far' I just always use HEAD~10 even
if it's just for the last or so commit.

 Would there be any objections to making  'git rebase -i' default to
HEAD~10  or maybe 16 or 20.  Having sensible defaults for commands
helps a bit with making it easier to use.

I think the following might be reasonable to support:

$ git rebase -i -10
$ git rebase -i -n -10

j.

Hi,

On Thu, 19 Feb 2009, Jay Soffian wrote:

On Thu, Feb 19, 2009 at 4:21 AM, John Tapsell [off-list ref] wrote:

quoted

 I often do 'git rebase -i HEAD~10' to rebase.  Since afaics it 
doesn't matter if you go back 'too far' I just always use HEAD~10 even 
if it's just for the last or so commit.

 Would there be any objections to making 'git rebase -i' default to 
HEAD~10 or maybe 16 or 20.  Having sensible defaults for commands 
helps a bit with making it easier to use.

I think the following might be reasonable to support:

$ git rebase -i -10
$ git rebase -i -n -10

I disagree.

You think -10 would be the same as HEAD~10?  Think again.  And include 
merge commits amongst the last 9 commits in your thoughts.

Once you thought about such a scenario, "-10" is probably no longer that 
attractive, right?

Ciao,
Dscho

On Thu, Feb 19, 2009 at 4:04 PM, Johannes Schindelin
[off-list ref] wrote:

You think -10 would be the same as HEAD~10?

I think it would mean the same thing to rebase as it does to format-patch.

I will now admit I haven't thought about what it means to format-patch
if there are merges. :-)

j.

On Thursday 19 February 2009 21:55, Jay Soffian wrote:

On Thu, Feb 19, 2009 at 4:21 AM, John Tapsell [off-list ref] wrote:

quoted

Hi,

 I often do   'git rebase -i HEAD~10'  to rebase.  Since afaics it
doesn't matter if you go back 'too far' I just always use HEAD~10 even
if it's just for the last or so commit.

 Would there be any objections to making  'git rebase -i' default to
HEAD~10  or maybe 16 or 20.  Having sensible defaults for commands
helps a bit with making it easier to use.

I think the following might be reasonable to support:

$ git rebase -i -10
$ git rebase -i -n -10

This feature gets my vote. I actually gave the implementation a quick try,
but didn't get very far through it. I was actually considering making git
rev-parse support the syntax.

Yes, as remarked by Johannes there are issue when there are merges in between
(in which case -10 is most likely not the same as HEAD~10), but I would say
that this is in no way a good reason to deprive users from the comfort it can
give in most common situations.

-- 
Giuseppe "Oblomov" Bilotta

Hi,

On Fri, 20 Feb 2009, Giuseppe Bilotta wrote:

On Thursday 19 February 2009 21:55, Jay Soffian wrote:

quoted

On Thu, Feb 19, 2009 at 4:21 AM, John Tapsell [off-list ref] wrote:

quoted

Hi,

 I often do   'git rebase -i HEAD~10'  to rebase.  Since afaics it
doesn't matter if you go back 'too far' I just always use HEAD~10 even
if it's just for the last or so commit.

 Would there be any objections to making  'git rebase -i' default to
HEAD~10  or maybe 16 or 20.  Having sensible defaults for commands
helps a bit with making it easier to use.

I think the following might be reasonable to support:

$ git rebase -i -10
$ git rebase -i -n -10

This feature gets my vote. I actually gave the implementation a quick try,
but didn't get very far through it. I was actually considering making git
rev-parse support the syntax.

Yes, as remarked by Johannes there are issue when there are merges in between
(in which case -10 is most likely not the same as HEAD~10), but I would say
that this is in no way a good reason to deprive users from the comfort it can
give in most common situations.

"I want it, I want it, I want it, and I'll just ignore what you just said" 
is not a good counterargument, would you say?

Sure, you even cited me, responding to the mail I responded to (as opposed 
to my mail), but you managed to ignore my argument nevertheless.

Ciao,
Dscho

Jay Soffian [off-list ref] writes:

On Thu, Feb 19, 2009 at 4:21 AM, John Tapsell [off-list ref] wrote:

quoted

Hi,

 I often do   'git rebase -i HEAD~10'  to rebase.  Since afaics it
doesn't matter if you go back 'too far' I just always use HEAD~10 even
if it's just for the last or so commit.

 Would there be any objections to making  'git rebase -i' default to
HEAD~10  or maybe 16 or 20.  Having sensible defaults for commands
helps a bit with making it easier to use.

I think the following might be reasonable to support:

$ git rebase -i -10
$ git rebase -i -n -10

The syntax would certainly imply a different semantics from giving
HEAD~10.  How would you compute the set of commits to rebase sanely when
you have merges after your 10th direct parent commit?

On Thu, Feb 19, 2009 at 7:11 PM, Junio C Hamano [off-list ref] wrote:

quoted

$ git rebase -i -10
$ git rebase -i -n -10

The syntax would certainly imply a different semantics from giving
HEAD~10.  How would you compute the set of commits to rebase sanely when
you have merges after your 10th direct parent commit?

I didn't mean to suggest that -10 and HEAD~10 are the same thing.

I would expect -10 to act the same when given to rebase as it does
when given to format-patch. In both cases, you are asking the command
for a set of commits.

But as I said, I don't exactly know what -10 means to format-patch if
there are merge commits because I've never tried to use it in such a
context.

j.

Jay Soffian venit, vidit, dixit 20.02.2009 01:26:

On Thu, Feb 19, 2009 at 7:11 PM, Junio C Hamano [off-list ref] wrote:

quoted

quoted

$ git rebase -i -10
$ git rebase -i -n -10

The syntax would certainly imply a different semantics from giving
HEAD~10.  How would you compute the set of commits to rebase sanely when
you have merges after your 10th direct parent commit?

I didn't mean to suggest that -10 and HEAD~10 are the same thing.

I would expect -10 to act the same when given to rebase as it does
when given to format-patch. In both cases, you are asking the command
for a set of commits.

But as I said, I don't exactly know what -10 means to format-patch if
there are merge commits because I've never tried to use it in such a
context.

j.

I guess it means exactly what

git rev-list -10 HEAD

means. And that would also be the easy way to implement it.

BUT: The fact that it's not obvious what "-10" is in non-linear
situations is the reason why it's probably not a good idea for r-b-i. If
you want to rebase you need a clear picture of the revision graph. If
you have one you know where to rebase from, and how to say so using
HEAD~5 and such. If you don't have one then using an option like -10
could be dangerous. And in a linear situation, -10 is equivalent to
HEAD~10 (+-1 ...).

Michael