git rebase -i

git rebase -i

[John Tapsell]

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

Re: git rebase -i

[Wincent Colaiuta]

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

Re: git rebase -i

[John Tapsell]

2009/2/19 Wincent Colaiuta <win@wincent.com>:
> 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.)

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

Re: git rebase -i

[Wincent Colaiuta]

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

> 2009/2/19 Wincent Colaiuta <win@wincent.com>:
>> 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.)
>
> 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

Re: git rebase -i

[Jeff King]

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

>> 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

Re: git rebase -i

[Wincent Colaiuta]

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

> On Thu, Feb 19, 2009 at 10:59:15AM +0100, Wincent Colaiuta wrote:
>
>>> 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

Re: git rebase -i

[Jeff King]

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

>> 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".

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

Re: git rebase -i

[Theodore Tso]

On Thu, Feb 19, 2009 at 05:20:53AM -0500, Jeff King wrote:
> > 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".
> 
> 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

Re: git rebase -i

[Teemu Likonen]

On 2009-02-19 09:21 (UTC), 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.
>
>   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 it's better to use aliases for this kind of personal things:

    git config --global alias.my-rebase "rebase -i HEAD~10"

Now you can do:

    git my-rebase

Re: git rebase -i

[John Tapsell]

2009/2/19 Teemu Likonen <tlikonen@iki.fi>:
> On 2009-02-19 09:21 (UTC), 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.
>>
>>   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 it's better to use aliases for this kind of personal things:
>
>    git config --global alias.my-rebase "rebase -i HEAD~10"
>
> Now you can do:
>
>    git my-rebase
>

I'm trying to make git more obvious and easier to use, rather than
find any solution :-)

Re: git rebase -i

[Sitaram Chamarty]

On 2009-02-19, John Tapsell <johnflux@gmail.com> wrote:
> 2009/2/19 Teemu Likonen <tlikonen@iki.fi>:
>> I think it's better to use aliases for this kind of personal things:
>>
>>    git config --global alias.my-rebase "rebase -i HEAD~10"

perfectly reasonable

> I'm trying to make git more obvious and easier to use, rather than
> find any solution :-)

I'm sorry I don't know what is obvious about any specific
number, unless it is 42 ;-)

Seriously, forcing *some* default simply because some people
use it with that value does not make it obvious to anyone
but those few.  I'm not even arguing about the number; I'd
hate to have *any* number be the default.

Re: git rebase -i

[John Tapsell]

2009/2/19 Sitaram Chamarty <sitaramc@gmail.com>:
> On 2009-02-19, John Tapsell <johnflux@gmail.com> wrote:
>> 2009/2/19 Teemu Likonen <tlikonen@iki.fi>:
>>> I think it's better to use aliases for this kind of personal things:
>>>
>>>    git config --global alias.my-rebase "rebase -i HEAD~10"
>
> perfectly reasonable
>
>> I'm trying to make git more obvious and easier to use, rather than
>> find any solution :-)
>
> I'm sorry I don't know what is obvious about any specific
> number, unless it is 42 ;-)
>
> Seriously, forcing *some* default simply because some people
> use it with that value does not make it obvious to anyone
> but those few.  I'm not even arguing about the number; I'd
> hate to have *any* number be the default.

Yep.  Some other people have come up with some pretty good ideas.
Maybe defaulting to 'origin' or something is the best way forward.

John

Re: git rebase -i

[Stephan Beyer]

Hi,

> > I think it's better to use aliases for this kind of personal things:
> >
> >    git config --global alias.my-rebase "rebase -i HEAD~10"
> >
> > Now you can do:
> >
> >    git my-rebase
> >
> 
> I'm trying to make git more obvious and easier to use, rather than
> find any solution :-)

As Wincent pointed out, git rebase -i without arguments isn't that
obvious or intuitive.

If you was looking for a solution, I'd be telling you that I use a
simple script "git-tickle-last" for this purpose:

--- 8< ---
#!/bin/sh
default=10

get_safe_num () {
	n=0
	git rev-list --parents "HEAD~$default.." | while read line
	do
		i=0
		for p in $line
		do
			i=$((i+1))
		done
		if test "$i" -gt 2
		then
			echo $n
			return 1
		fi
		n=$((n+1))
	done && echo $default
}

git rebase -i "HEAD~$(get_safe_num)"
--- >8---

It makes sure (I hope) that no merges get into the list, but it doesn't
care about published changes (i.e. tracking branch behavior).

I use it because I often reorder or squash commits before I push or
merge.

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

Re: git rebase -i

[Pieter de Bie]

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.

Re: git rebase -i

[Junio C Hamano]

Pieter de Bie <pdebie@ai.rug.nl> writes:

> 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.

I'd say that might be a very sane default for users or "branch --track"
and/or "pull --rebase", both for i-rebase and rebase.

Re: git rebase -i

[Marc Branchaud]

Junio C Hamano wrote:
> 
>> I'd prefer something a bit less arbitrary, like using the tracked head
>> for a tracking branch.
> 
> I'd say that might be a very sane default for users or "branch --track"
> and/or "pull --rebase", both for i-rebase and rebase.

That's how I work, but even if that were the default I think I'd always specify the tracked branch head anyway.  It's good to always be specific with a powerful command like rebase.

		M.

Re: git rebase -i

[Nazri Ramliy]

I think it's about time to put this bikeshed argument to rest.

*ducks*

nazri.

Re: git rebase -i

[Thomas Rast]

[-- Attachment #1: Type: text/plain, Size: 333 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: git rebase -i

[John Tapsell]

2009/2/19 Thomas Rast <trast@student.ethz.ch>:
> 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.

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

Re: git rebase -i

[Jeff King]

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

Re: git rebase -i

[Jay Soffian]

On Thu, Feb 19, 2009 at 4:21 AM, John Tapsell <johnflux@gmail.com> 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.

Re: git rebase -i

[Johannes Schindelin]

Hi,

On Thu, 19 Feb 2009, Jay Soffian wrote:

> On Thu, Feb 19, 2009 at 4:21 AM, John Tapsell <johnflux@gmail.com> 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.
> >
> >  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

Re: git rebase -i

[Jay Soffian]

On Thu, Feb 19, 2009 at 4:04 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> 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.

Re: git rebase -i

[Giuseppe Bilotta]

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

> On Thu, Feb 19, 2009 at 4:21 AM, John Tapsell <johnflux@gmail.com> 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

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

Re: git rebase -i

[Johannes Schindelin]

Hi,

On Fri, 20 Feb 2009, Giuseppe Bilotta wrote:

> On Thursday 19 February 2009 21:55, Jay Soffian wrote:
> 
> > On Thu, Feb 19, 2009 at 4:21 AM, John Tapsell <johnflux@gmail.com> 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
> 
> 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

Re: git rebase -i

[Junio C Hamano]

Jay Soffian <jaysoffian@gmail.com> writes:

> On Thu, Feb 19, 2009 at 4:21 AM, John Tapsell <johnflux@gmail.com> 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

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?

Re: git rebase -i

[Jay Soffian]

On Thu, Feb 19, 2009 at 7:11 PM, Junio C Hamano <gitster@pobox.com> wrote:

>> $ 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.

Re: git rebase -i

[Michael J Gruber]

Jay Soffian venit, vidit, dixit 20.02.2009 01:26:
> On Thu, Feb 19, 2009 at 7:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 
>>> $ 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