John TapsellHi,
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
Wincent ColaiutaRe: git rebase -i
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
John TapsellRe: git rebase -i
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
Wincent ColaiutaRe: git rebase -i
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
Jeff KingRe: git rebase -i
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
Wincent ColaiutaRe: git rebase -i
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
Jeff KingRe: git rebase -i
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
Theodore TsoRe: git rebase -i
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
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
John TapsellRe: git rebase -i
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 :-)
Sitaram ChamartyRe: git rebase -i
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.
John TapsellRe: git rebase -i
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
Stephan BeyerRe: git rebase -i
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
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.
Junio C HamanoRe: git rebase -i
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.
Marc BranchaudRe: git rebase -i
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.
Nazri RamliyRe: git rebase -i
I think it's about time to put this bikeshed argument to rest.
*ducks*
nazri.
Thomas RastRe: git rebase -i
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.chJohn TapsellRe: git rebase -i
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 :-)
Jeff KingRe: git rebase -i
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
Jay SoffianRe: git rebase -i
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.
Johannes SchindelinRe: git rebase -i
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
Jay SoffianRe: git rebase -i
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.
Giuseppe BilottaRe: git rebase -i
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
Johannes SchindelinRe: git rebase -i
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
Junio C HamanoRe: git rebase -i
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?
Jay SoffianRe: git rebase -i
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.
Michael J GruberRe: git rebase -i
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