# git rebase -i 28 messages from 2009-02-19 to 2009-02-23. Participants: John Tapsell, Wincent Colaiuta, Teemu Likonen, Pieter de Bie, Thomas Rast, Jeff King, Junio C Hamano, Sitaram Chamarty, Theodore Tso, Marc Branchaud, Nazri Ramliy, Jay Soffian, Johannes Schindelin, Giuseppe Bilotta, Michael J Gruber, Stephan Beyer. Thread: https://gitlist.dev/t/17896 ## John Tapsell, 2009-02-19 09:21 Subject: git rebase -i Message-ID: <43d8ce650902190121v2e18aac1rfaa64a4ce6e799a3@mail.gmail.com> URL: https://gitlist.dev/e/43d8ce650902190121v2e18aac1rfaa64a4ce6e799a3%40mail.gmail.com ``` 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 ``` ## Wincent Colaiuta, 2009-02-19 09:36 Subject: Re: git rebase -i Message-ID: URL: https://gitlist.dev/e/A3E3A7A0-F03F-4C8B-B3F8-756B0E89798C%40wincent.com In-Reply-To: <43d8ce650902190121v2e18aac1rfaa64a4ce6e799a3@mail.gmail.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.) Cheers, Wincent ``` ## Teemu Likonen, 2009-02-19 09:50 Subject: Re: git rebase -i Message-ID: <871vtudabm.fsf@iki.fi> URL: https://gitlist.dev/e/871vtudabm.fsf%40iki.fi In-Reply-To: <43d8ce650902190121v2e18aac1rfaa64a4ce6e799a3@mail.gmail.com> ``` 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 Tapsell, 2009-02-19 09:52 Subject: Re: git rebase -i Message-ID: <43d8ce650902190152t6162593x8d0920be0e6d7a6d@mail.gmail.com> URL: https://gitlist.dev/e/43d8ce650902190152t6162593x8d0920be0e6d7a6d%40mail.gmail.com In-Reply-To: <871vtudabm.fsf@iki.fi> ``` 2009/2/19 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 > I'm trying to make git more obvious and easier to use, rather than find any solution :-) ``` ## John Tapsell, 2009-02-19 09:55 Subject: Re: git rebase -i Message-ID: <43d8ce650902190155m4de23643r8a9d3c35686ea4e9@mail.gmail.com> URL: https://gitlist.dev/e/43d8ce650902190155m4de23643r8a9d3c35686ea4e9%40mail.gmail.com In-Reply-To: ``` 2009/2/19 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.) 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 Colaiuta, 2009-02-19 09:59 Subject: Re: git rebase -i Message-ID: <2A7CAA9F-DB42-4782-BF61-41E8DA577DF2@wincent.com> URL: https://gitlist.dev/e/2A7CAA9F-DB42-4782-BF61-41E8DA577DF2%40wincent.com In-Reply-To: <43d8ce650902190155m4de23643r8a9d3c35686ea4e9@mail.gmail.com> ``` El 19/2/2009, a las 10:55, John Tapsell escribió: > 2009/2/19 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.) > > 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 ``` ## Pieter de Bie, 2009-02-19 10:00 Subject: Re: git rebase -i Message-ID: URL: https://gitlist.dev/e/FEE581A3-C858-45CF-B545-8F7187FCCE40%40ai.rug.nl In-Reply-To: <43d8ce650902190121v2e18aac1rfaa64a4ce6e799a3@mail.gmail.com> ``` 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. ``` ## Thomas Rast, 2009-02-19 10:01 Subject: Re: git rebase -i Message-ID: <200902191101.35310.trast@student.ethz.ch> URL: https://gitlist.dev/e/200902191101.35310.trast%40student.ethz.ch In-Reply-To: <43d8ce650902190121v2e18aac1rfaa64a4ce6e799a3@mail.gmail.com> ``` 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 ``` ## John Tapsell, 2009-02-19 10:03 Subject: Re: git rebase -i Message-ID: <43d8ce650902190203i4708f2b6r33aa1d856b89bb45@mail.gmail.com> URL: https://gitlist.dev/e/43d8ce650902190203i4708f2b6r33aa1d856b89bb45%40mail.gmail.com In-Reply-To: <200902191101.35310.trast@student.ethz.ch> ``` 2009/2/19 Thomas Rast : > 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 King, 2009-02-19 10:07 Subject: Re: git rebase -i Message-ID: <20090219100743.GA16119@coredump.intra.peff.net> URL: https://gitlist.dev/e/20090219100743.GA16119%40coredump.intra.peff.net In-Reply-To: <43d8ce650902190121v2e18aac1rfaa64a4ce6e799a3@mail.gmail.com> ``` 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 ``` ## Junio C Hamano, 2009-02-19 10:09 Subject: Re: git rebase -i Message-ID: <7v63j6oi0d.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7v63j6oi0d.fsf%40gitster.siamese.dyndns.org In-Reply-To: ``` Pieter de Bie 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. ``` ## Jeff King, 2009-02-19 10:11 Subject: Re: git rebase -i Message-ID: <20090219101154.GB16119@coredump.intra.peff.net> URL: https://gitlist.dev/e/20090219101154.GB16119%40coredump.intra.peff.net In-Reply-To: <2A7CAA9F-DB42-4782-BF61-41E8DA577DF2@wincent.com> ``` 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 Colaiuta, 2009-02-19 10:15 Subject: Re: git rebase -i Message-ID: <6887C6DB-E9C8-4DC8-BD1E-C20E92271FA5@wincent.com> URL: https://gitlist.dev/e/6887C6DB-E9C8-4DC8-BD1E-C20E92271FA5%40wincent.com In-Reply-To: <20090219101154.GB16119@coredump.intra.peff.net> ``` 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 King, 2009-02-19 10:20 Subject: Re: git rebase -i Message-ID: <20090219102053.GA17417@coredump.intra.peff.net> URL: https://gitlist.dev/e/20090219102053.GA17417%40coredump.intra.peff.net In-Reply-To: <6887C6DB-E9C8-4DC8-BD1E-C20E92271FA5@wincent.com> ``` 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 ``` ## Sitaram Chamarty, 2009-02-19 14:02 Subject: Re: git rebase -i Message-ID: URL: https://gitlist.dev/e/slrngpqpjt.j03.sitaramc%40sitaramc.homelinux.net In-Reply-To: <43d8ce650902190152t6162593x8d0920be0e6d7a6d@mail.gmail.com> ``` On 2009-02-19, John Tapsell wrote: > 2009/2/19 Teemu Likonen : >> 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 Tapsell, 2009-02-19 14:24 Subject: Re: git rebase -i Message-ID: <43d8ce650902190624q40bc4d96hbacd505350d72eb4@mail.gmail.com> URL: https://gitlist.dev/e/43d8ce650902190624q40bc4d96hbacd505350d72eb4%40mail.gmail.com In-Reply-To: ``` 2009/2/19 Sitaram Chamarty : > On 2009-02-19, John Tapsell wrote: >> 2009/2/19 Teemu Likonen : >>> 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 ``` ## Theodore Tso, 2009-02-19 14:57 Subject: Re: git rebase -i Message-ID: <20090219145715.GC14810@mini-me.lan> URL: https://gitlist.dev/e/20090219145715.GC14810%40mini-me.lan In-Reply-To: <20090219102053.GA17417@coredump.intra.peff.net> ``` 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 ``` ## Marc Branchaud, 2009-02-19 16:12 Subject: Re: git rebase -i Message-ID: <499D84E8.1020505@xiplink.com> URL: https://gitlist.dev/e/499D84E8.1020505%40xiplink.com In-Reply-To: <7v63j6oi0d.fsf@gitster.siamese.dyndns.org> ``` 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 Ramliy, 2009-02-19 17:53 Subject: Re: git rebase -i Message-ID: <544dda350902190953w6a3fc71br3235b7aa84933598@mail.gmail.com> URL: https://gitlist.dev/e/544dda350902190953w6a3fc71br3235b7aa84933598%40mail.gmail.com In-Reply-To: <499D84E8.1020505@xiplink.com> ``` I think it's about time to put this bikeshed argument to rest. *ducks* nazri. ``` ## Jay Soffian, 2009-02-19 20:55 Subject: Re: git rebase -i Message-ID: <76718490902191255w24b30bd8jacaed8aa919d6526@mail.gmail.com> URL: https://gitlist.dev/e/76718490902191255w24b30bd8jacaed8aa919d6526%40mail.gmail.com In-Reply-To: <43d8ce650902190121v2e18aac1rfaa64a4ce6e799a3@mail.gmail.com> ``` On Thu, Feb 19, 2009 at 4:21 AM, John Tapsell 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 Schindelin, 2009-02-19 21:04 Subject: Re: git rebase -i Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.0902192203280.6223%40intel-tinevez-2-302 In-Reply-To: <76718490902191255w24b30bd8jacaed8aa919d6526@mail.gmail.com> ``` Hi, On Thu, 19 Feb 2009, Jay Soffian wrote: > On Thu, Feb 19, 2009 at 4:21 AM, 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 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 Soffian, 2009-02-19 21:07 Subject: Re: git rebase -i Message-ID: <76718490902191307h39e4dd02nafb8ef02d670dc57@mail.gmail.com> URL: https://gitlist.dev/e/76718490902191307h39e4dd02nafb8ef02d670dc57%40mail.gmail.com In-Reply-To: ``` On Thu, Feb 19, 2009 at 4:04 PM, Johannes Schindelin 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 Bilotta, 2009-02-19 23:53 Subject: Re: git rebase -i Message-ID: URL: https://gitlist.dev/e/gnkre1%24g8s%241%40ger.gmane.org In-Reply-To: <76718490902191255w24b30bd8jacaed8aa919d6526@mail.gmail.com> ``` On Thursday 19 February 2009 21:55, Jay Soffian wrote: > On Thu, Feb 19, 2009 at 4:21 AM, John Tapsell 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 Schindelin, 2009-02-20 00:07 Subject: Re: git rebase -i Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.0902200105520.10279%40pacific.mpi-cbg.de In-Reply-To: ``` 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 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 Hamano, 2009-02-20 00:11 Subject: Re: git rebase -i Message-ID: <7vzlgij7cb.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vzlgij7cb.fsf%40gitster.siamese.dyndns.org In-Reply-To: <76718490902191255w24b30bd8jacaed8aa919d6526@mail.gmail.com> ``` Jay Soffian writes: > On Thu, Feb 19, 2009 at 4:21 AM, John Tapsell 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 Soffian, 2009-02-20 00:26 Subject: Re: git rebase -i Message-ID: <76718490902191626u2202ed38xf63111b6a2758206@mail.gmail.com> URL: https://gitlist.dev/e/76718490902191626u2202ed38xf63111b6a2758206%40mail.gmail.com In-Reply-To: <7vzlgij7cb.fsf@gitster.siamese.dyndns.org> ``` On Thu, Feb 19, 2009 at 7:11 PM, Junio C Hamano 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 Gruber, 2009-02-20 11:02 Subject: Re: git rebase -i Message-ID: <499E8DB9.5030505@drmicha.warpmail.net> URL: https://gitlist.dev/e/499E8DB9.5030505%40drmicha.warpmail.net In-Reply-To: <76718490902191626u2202ed38xf63111b6a2758206@mail.gmail.com> ``` Jay Soffian venit, vidit, dixit 20.02.2009 01:26: > On Thu, Feb 19, 2009 at 7:11 PM, Junio C Hamano 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 ``` ## Stephan Beyer, 2009-02-23 00:32 Subject: Re: git rebase -i Message-ID: <20090223003245.GC21616@leksak.fem-net> URL: https://gitlist.dev/e/20090223003245.GC21616%40leksak.fem-net In-Reply-To: <43d8ce650902190152t6162593x8d0920be0e6d7a6d@mail.gmail.com> ``` 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 , PGP 0x6EDDD207FCC5040F ```