{"thread":{"id":"17896","subject":"git rebase -i","startedAt":"2009-02-19T09:21:49Z","lastAt":"2009-02-23T00:32:45Z","messageCount":28,"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"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"105416","messageId":"43d8ce650902190121v2e18aac1rfaa64a4ce6e799a3@mail.gmail.com","threadId":"17896","inReplyTo":null,"subject":"git rebase -i","fromName":"John Tapsell","fromEmail":"johnflux@gmail.com","sentAt":"2009-02-19T09:21:49Z","receivedAt":"2009-02-19T09:21:49Z","isPatch":false,"sender":{"key":"johnflux@gmail.com","avatar":"https://gravatar.com/avatar/25f70d4c0f96396b84a2e34bcd9bdc233462c7b4be29b5fdca8266fc53f30b0c?d=mp&s=160"},"body":"Hi,\n\n I often do 'git rebase -i HEAD~10' to rebase. Since afaics it\ndoesn't matter if you go back 'too far' I just always use HEAD~10 even\nif it's just for the last or so commit.\n\n Would there be any objections to making 'git rebase -i' default to\nHEAD~10 or maybe 16 or 20. Having sensible defaults for commands\nhelps a bit with making it easier to use.\n\nJohn\n"},{"id":"105417","messageId":"A3E3A7A0-F03F-4C8B-B3F8-756B0E89798C@wincent.com","threadId":"17896","inReplyTo":"43d8ce650902190121v2e18aac1rfaa64a4ce6e799a3@mail.gmail.com","subject":"Re: git rebase -i","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2009-02-19T09:36:40Z","receivedAt":"2009-02-19T09:36:40Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 19/2/2009, a las 10:21, John Tapsell escribió:\n\n> Hi,\n>\n> I often do 'git rebase -i HEAD~10' to rebase. Since afaics it\n> doesn't matter if you go back 'too far' I just always use HEAD~10 even\n> if it's just for the last or so commit.\n>\n> Would there be any objections to making 'git rebase -i' default to\n> HEAD~10 or maybe 16 or 20.\n\nSounds awfully arbitrary and counter-intuitive to me.\n\nTake a sample of Git users who know what \"git rebase\" does and ask \nthem what they intuitively think \"git rebase -i\" without any \nadditional arguments should do; I'd be _extremely_ surprised if they \nanswered that it should default to HEAD~10, HEAD~16, HEAD~20, or \nHEAD~N for any N.\n\n(I could tell you what my intuition tells me, but I don't think it's \nvery interesting.)\n\nCheers,\nWincent\n"},{"id":"105418","messageId":"871vtudabm.fsf@iki.fi","threadId":"17896","inReplyTo":"43d8ce650902190121v2e18aac1rfaa64a4ce6e799a3@mail.gmail.com","subject":"Re: git rebase -i","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2009-02-19T09:50:53Z","receivedAt":"2009-02-19T09:50:53Z","isPatch":false,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"On 2009-02-19 09:21 (UTC), John Tapsell wrote:\n\n> I often do 'git rebase -i HEAD~10' to rebase. Since afaics it\n> doesn't matter if you go back 'too far' I just always use HEAD~10 even\n> if it's just for the last or so commit.\n>\n> Would there be any objections to making 'git rebase -i' default to\n> HEAD~10 or maybe 16 or 20. Having sensible defaults for commands\n> helps a bit with making it easier to use.\n\nI think it's better to use aliases for this kind of personal things:\n\n git config --global alias.my-rebase \"rebase -i HEAD~10\"\n\nNow you can do:\n\n git my-rebase\n"},{"id":"105419","messageId":"43d8ce650902190152t6162593x8d0920be0e6d7a6d@mail.gmail.com","threadId":"17896","inReplyTo":"871vtudabm.fsf@iki.fi","subject":"Re: git rebase -i","fromName":"John Tapsell","fromEmail":"johnflux@gmail.com","sentAt":"2009-02-19T09:52:29Z","receivedAt":"2009-02-19T09:52:29Z","isPatch":false,"sender":{"key":"johnflux@gmail.com","avatar":"https://gravatar.com/avatar/25f70d4c0f96396b84a2e34bcd9bdc233462c7b4be29b5fdca8266fc53f30b0c?d=mp&s=160"},"body":"2009/2/19 Teemu Likonen :\n> On 2009-02-19 09:21 (UTC), John Tapsell wrote:\n>\n>> I often do 'git rebase -i HEAD~10' to rebase. Since afaics it\n>> doesn't matter if you go back 'too far' I just always use HEAD~10 even\n>> if it's just for the last or so commit.\n>>\n>> Would there be any objections to making 'git rebase -i' default to\n>> HEAD~10 or maybe 16 or 20. Having sensible defaults for commands\n>> helps a bit with making it easier to use.\n>\n> I think it's better to use aliases for this kind of personal things:\n>\n> git config --global alias.my-rebase \"rebase -i HEAD~10\"\n>\n> Now you can do:\n>\n> git my-rebase\n>\n\nI'm trying to make git more obvious and easier to use, rather than\nfind any solution :-)\n"},{"id":"105420","messageId":"43d8ce650902190155m4de23643r8a9d3c35686ea4e9@mail.gmail.com","threadId":"17896","inReplyTo":"A3E3A7A0-F03F-4C8B-B3F8-756B0E89798C@wincent.com","subject":"Re: git rebase -i","fromName":"John Tapsell","fromEmail":"johnflux@gmail.com","sentAt":"2009-02-19T09:55:27Z","receivedAt":"2009-02-19T09:55:27Z","isPatch":false,"sender":{"key":"johnflux@gmail.com","avatar":"https://gravatar.com/avatar/25f70d4c0f96396b84a2e34bcd9bdc233462c7b4be29b5fdca8266fc53f30b0c?d=mp&s=160"},"body":"2009/2/19 Wincent Colaiuta :\n> El 19/2/2009, a las 10:21, John Tapsell escribió:\n>\n>> Hi,\n>>\n>> I often do 'git rebase -i HEAD~10' to rebase. Since afaics it\n>> doesn't matter if you go back 'too far' I just always use HEAD~10 even\n>> if it's just for the last or so commit.\n>>\n>> Would there be any objections to making 'git rebase -i' default to\n>> HEAD~10 or maybe 16 or 20.\n>\n> Sounds awfully arbitrary and counter-intuitive to me.\n>\n> Take a sample of Git users who know what \"git rebase\" does and ask them what\n> they intuitively think \"git rebase -i\" without any additional arguments\n> should do; I'd be _extremely_ surprised if they answered that it should\n> default to HEAD~10, HEAD~16, HEAD~20, or HEAD~N for any N.\n>\n> (I could tell you what my intuition tells me, but I don't think it's very\n> interesting.)\n\nIt doesn't really matter if the user manages to guess what the number\nN is, just that it's \"recent commits\".\n\nIf a sample of git users would expect \"git rebase -i\" to let you\nrebase the last few commits, then it doesn't really matter all that\nmuch what N is. 10 seems a reasonable default as any.\n\nJohn\n"},{"id":"105421","messageId":"2A7CAA9F-DB42-4782-BF61-41E8DA577DF2@wincent.com","threadId":"17896","inReplyTo":"43d8ce650902190155m4de23643r8a9d3c35686ea4e9@mail.gmail.com","subject":"Re: git rebase -i","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2009-02-19T09:59:15Z","receivedAt":"2009-02-19T09:59:15Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 19/2/2009, a las 10:55, John Tapsell escribió:\n\n> 2009/2/19 Wincent Colaiuta :\n>> El 19/2/2009, a las 10:21, John Tapsell escribió:\n>>\n>>> Hi,\n>>>\n>>> I often do 'git rebase -i HEAD~10' to rebase. Since afaics it\n>>> doesn't matter if you go back 'too far' I just always use HEAD~10 \n>>> even\n>>> if it's just for the last or so commit.\n>>>\n>>> Would there be any objections to making 'git rebase -i' default to\n>>> HEAD~10 or maybe 16 or 20.\n>>\n>> Sounds awfully arbitrary and counter-intuitive to me.\n>>\n>> Take a sample of Git users who know what \"git rebase\" does and ask \n>> them what\n>> they intuitively think \"git rebase -i\" without any additional \n>> arguments\n>> should do; I'd be _extremely_ surprised if they answered that it \n>> should\n>> default to HEAD~10, HEAD~16, HEAD~20, or HEAD~N for any N.\n>>\n>> (I could tell you what my intuition tells me, but I don't think \n>> it's very\n>> interesting.)\n>\n> It doesn't really matter if the user manages to guess what the number\n> N is, just that it's \"recent commits\".\n>\n> If a sample of git users would expect \"git rebase -i\" to let you\n> rebase the last few commits, then it doesn't really matter all that\n> much what N is. 10 seems a reasonable default as any.\n\nThat's exactly the problem. Most git users aren't going to expect \"git \nrebase -i\" to let you \"rebase the last few commits\".\n\nRebase is mostly used, talked about, and conceptualized in terms of \nrebasing onto other _branches_.\n\nCheers,\nWincent\n"},{"id":"105422","messageId":"FEE581A3-C858-45CF-B545-8F7187FCCE40@ai.rug.nl","threadId":"17896","inReplyTo":"43d8ce650902190121v2e18aac1rfaa64a4ce6e799a3@mail.gmail.com","subject":"Re: git rebase -i","fromName":"Pieter de Bie","fromEmail":"pdebie@ai.rug.nl","sentAt":"2009-02-19T10:00:53Z","receivedAt":"2009-02-19T10:00:53Z","isPatch":false,"sender":{"key":"pdebie@ai.rug.nl","avatar":null},"body":"\nOn 19 feb 2009, at 09:21, John Tapsell wrote:\n\n> Would there be any objections to making 'git rebase -i' default to\n> HEAD~10 or maybe 16 or 20. Having sensible defaults for commands\n> helps a bit with making it easier to use.\n\nI'd prefer something a bit less arbitrary, like using the tracked head\nfor a tracking branch.\n"},{"id":"105423","messageId":"200902191101.35310.trast@student.ethz.ch","threadId":"17896","inReplyTo":"43d8ce650902190121v2e18aac1rfaa64a4ce6e799a3@mail.gmail.com","subject":"Re: git rebase -i","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-02-19T10:01:30Z","receivedAt":"2009-02-19T10:01:30Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"John Tapsell wrote:\n> I often do 'git rebase -i HEAD~10' to rebase. Since afaics it\n> doesn't matter if you go back 'too far' I just always use HEAD~10 even\n> if it's just for the last or so commit.\n\nIt makes a *huge* difference if any of those last N commits is a merge.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"105424","messageId":"43d8ce650902190203i4708f2b6r33aa1d856b89bb45@mail.gmail.com","threadId":"17896","inReplyTo":"200902191101.35310.trast@student.ethz.ch","subject":"Re: git rebase -i","fromName":"John Tapsell","fromEmail":"johnflux@gmail.com","sentAt":"2009-02-19T10:03:21Z","receivedAt":"2009-02-19T10:03:21Z","isPatch":false,"sender":{"key":"johnflux@gmail.com","avatar":"https://gravatar.com/avatar/25f70d4c0f96396b84a2e34bcd9bdc233462c7b4be29b5fdca8266fc53f30b0c?d=mp&s=160"},"body":"2009/2/19 Thomas Rast :\n> John Tapsell wrote:\n>> I often do 'git rebase -i HEAD~10' to rebase. Since afaics it\n>> doesn't matter if you go back 'too far' I just always use HEAD~10 even\n>> if it's just for the last or so commit.\n>\n> It makes a *huge* difference if any of those last N commits is a merge.\n\nLots of good points. I'll leave this idea for now then :-)\n"},{"id":"105426","messageId":"20090219100743.GA16119@coredump.intra.peff.net","threadId":"17896","inReplyTo":"43d8ce650902190121v2e18aac1rfaa64a4ce6e799a3@mail.gmail.com","subject":"Re: git rebase -i","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-19T10:07:44Z","receivedAt":"2009-02-19T10:07:44Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 19, 2009 at 09:21:49AM +0000, John Tapsell wrote:\n\n> I often do 'git rebase -i HEAD~10' to rebase. Since afaics it\n> doesn't matter if you go back 'too far' I just always use HEAD~10 even\n> if it's just for the last or so commit.\n\nHere are some reasons not to go back too far:\n\n 1. The commits are displayed in order, so the ones that are\n interesting to the user are at the bottom. And HEAD~10 may display\n more than 10 commits in the face of non-linear history.\n\n 2. rebase -i does not preserve merges by default. Which means that if\n HEAD~10 is not a linear history, then you are flattening the graph\n structure.\n\n> Would there be any objections to making 'git rebase -i' default to\n> HEAD~10 or maybe 16 or 20. Having sensible defaults for commands\n> helps a bit with making it easier to use.\n\nIf you wanted to do something like this, a much more sensible cutoff\nwould be the location of an upstream tracking branch (e.g., as defined\nby branch.*.rebase). Then you are literally asking for commits which\nhave not been published in your upstream, which means it is OK to\nrewrite history (assuming they were not published elsewhere).\n\n-Peff\n"},{"id":"105427","messageId":"7v63j6oi0d.fsf@gitster.siamese.dyndns.org","threadId":"17896","inReplyTo":"FEE581A3-C858-45CF-B545-8F7187FCCE40@ai.rug.nl","subject":"Re: git rebase -i","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-19T10:09:22Z","receivedAt":"2009-02-19T10:09:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pieter de Bie writes:\n\n> On 19 feb 2009, at 09:21, John Tapsell wrote:\n>\n>> Would there be any objections to making 'git rebase -i' default to\n>> HEAD~10 or maybe 16 or 20. Having sensible defaults for commands\n>> helps a bit with making it easier to use.\n>\n> I'd prefer something a bit less arbitrary, like using the tracked head\n> for a tracking branch.\n\nI'd say that might be a very sane default for users or \"branch --track\"\nand/or \"pull --rebase\", both for i-rebase and rebase.\n"},{"id":"105429","messageId":"20090219101154.GB16119@coredump.intra.peff.net","threadId":"17896","inReplyTo":"2A7CAA9F-DB42-4782-BF61-41E8DA577DF2@wincent.com","subject":"Re: git rebase -i","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-19T10:11:54Z","receivedAt":"2009-02-19T10:11:54Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 19, 2009 at 10:59:15AM +0100, Wincent Colaiuta wrote:\n\n>> If a sample of git users would expect \"git rebase -i\" to let you\n>> rebase the last few commits, then it doesn't really matter all that\n>> much what N is. 10 seems a reasonable default as any.\n>\n> That's exactly the problem. Most git users aren't going to expect \"git \n> rebase -i\" to let you \"rebase the last few commits\".\n>\n> Rebase is mostly used, talked about, and conceptualized in terms of \n> rebasing onto other _branches_.\n\nActually, I don't think that's true anymore with \"rebase -i\"; it is\nprobably most convenient way in core git to rewrite the history of a\npatchset. E.g., a core part of my workflow as a contributor is:\n\n $ git checkout -b jk/topic origin\n $ while true; do hack hack hack; commit commit commit; done\n $ git rebase -i origin\n\nwhich gives me a list of everything on the topic, ready to be\nreordered, squashed, or edited as appropriate.\n\n-Peff\n"},{"id":"105430","messageId":"6887C6DB-E9C8-4DC8-BD1E-C20E92271FA5@wincent.com","threadId":"17896","inReplyTo":"20090219101154.GB16119@coredump.intra.peff.net","subject":"Re: git rebase -i","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2009-02-19T10:15:51Z","receivedAt":"2009-02-19T10:15:51Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 19/2/2009, a las 11:11, Jeff King escribió:\n\n> On Thu, Feb 19, 2009 at 10:59:15AM +0100, Wincent Colaiuta wrote:\n>\n>>> If a sample of git users would expect \"git rebase -i\" to let you\n>>> rebase the last few commits, then it doesn't really matter all that\n>>> much what N is. 10 seems a reasonable default as any.\n>>\n>> That's exactly the problem. Most git users aren't going to expect \n>> \"git\n>> rebase -i\" to let you \"rebase the last few commits\".\n>>\n>> Rebase is mostly used, talked about, and conceptualized in terms of\n>> rebasing onto other _branches_.\n>\n> Actually, I don't think that's true anymore with \"rebase -i\"; it is\n> probably most convenient way in core git to rewrite the history of a\n> patchset. E.g., a core part of my workflow as a contributor is:\n>\n> $ git checkout -b jk/topic origin\n> $ while true; do hack hack hack; commit commit commit; done\n> $ git rebase -i origin\n>\n> which gives me a list of everything on the topic, ready to be\n> reordered, squashed, or edited as appropriate.\n\nYes, I do the same. But notice that you did \"git rebase -i -- \n >>>origin<<<---\". Seems to me you are definitely _thinking_ in terms \nof your topic _branch_ and not in terms of \"the last few commits\".\n\nCheers,\nWincent\n"},{"id":"105433","messageId":"20090219102053.GA17417@coredump.intra.peff.net","threadId":"17896","inReplyTo":"6887C6DB-E9C8-4DC8-BD1E-C20E92271FA5@wincent.com","subject":"Re: git rebase -i","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-19T10:20:53Z","receivedAt":"2009-02-19T10:20:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 19, 2009 at 11:15:51AM +0100, Wincent Colaiuta wrote:\n\n>> Actually, I don't think that's true anymore with \"rebase -i\"; it is\n>> probably most convenient way in core git to rewrite the history of a\n>> patchset. E.g., a core part of my workflow as a contributor is:\n>>\n>> $ git checkout -b jk/topic origin\n>> $ while true; do hack hack hack; commit commit commit; done\n>> $ git rebase -i origin\n>>\n>> which gives me a list of everything on the topic, ready to be\n>> reordered, squashed, or edited as appropriate.\n>\n> Yes, I do the same. But notice that you did \"git rebase -i -- \n> >>>origin<<<---\". Seems to me you are definitely _thinking_ in terms of \n> your topic _branch_ and not in terms of \"the last few commits\".\n\nPerhaps. I think of it as \"the set of commits not yet published\"\n(since I publish only by sending patches to Junio, and he is my origin)\nand nothing to do with the topic branch itself.\n\nBut we are just quibbling over minor terminology. I think we both agree\nthat HEAD~10 is silly and abitrary.\n\n-Peff\n"},{"id":"105463","messageId":"slrngpqpjt.j03.sitaramc@sitaramc.homelinux.net","threadId":"17896","inReplyTo":"43d8ce650902190152t6162593x8d0920be0e6d7a6d@mail.gmail.com","subject":"Re: git rebase -i","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-02-19T14:02:37Z","receivedAt":"2009-02-19T14:02:37Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2009-02-19, John Tapsell wrote:\n> 2009/2/19 Teemu Likonen :\n>> I think it's better to use aliases for this kind of personal things:\n>>\n>> git config --global alias.my-rebase \"rebase -i HEAD~10\"\n\nperfectly reasonable\n\n> I'm trying to make git more obvious and easier to use, rather than\n> find any solution :-)\n\nI'm sorry I don't know what is obvious about any specific\nnumber, unless it is 42 ;-)\n\nSeriously, forcing *some* default simply because some people\nuse it with that value does not make it obvious to anyone\nbut those few. I'm not even arguing about the number; I'd\nhate to have *any* number be the default.\n"},{"id":"105470","messageId":"43d8ce650902190624q40bc4d96hbacd505350d72eb4@mail.gmail.com","threadId":"17896","inReplyTo":"slrngpqpjt.j03.sitaramc@sitaramc.homelinux.net","subject":"Re: git rebase -i","fromName":"John Tapsell","fromEmail":"johnflux@gmail.com","sentAt":"2009-02-19T14:24:05Z","receivedAt":"2009-02-19T14:24:05Z","isPatch":false,"sender":{"key":"johnflux@gmail.com","avatar":"https://gravatar.com/avatar/25f70d4c0f96396b84a2e34bcd9bdc233462c7b4be29b5fdca8266fc53f30b0c?d=mp&s=160"},"body":"2009/2/19 Sitaram Chamarty :\n> On 2009-02-19, John Tapsell wrote:\n>> 2009/2/19 Teemu Likonen :\n>>> I think it's better to use aliases for this kind of personal things:\n>>>\n>>> git config --global alias.my-rebase \"rebase -i HEAD~10\"\n>\n> perfectly reasonable\n>\n>> I'm trying to make git more obvious and easier to use, rather than\n>> find any solution :-)\n>\n> I'm sorry I don't know what is obvious about any specific\n> number, unless it is 42 ;-)\n>\n> Seriously, forcing *some* default simply because some people\n> use it with that value does not make it obvious to anyone\n> but those few. I'm not even arguing about the number; I'd\n> hate to have *any* number be the default.\n\nYep. Some other people have come up with some pretty good ideas.\nMaybe defaulting to 'origin' or something is the best way forward.\n\nJohn\n"},{"id":"105474","messageId":"20090219145715.GC14810@mini-me.lan","threadId":"17896","inReplyTo":"20090219102053.GA17417@coredump.intra.peff.net","subject":"Re: git rebase -i","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2009-02-19T14:57:15Z","receivedAt":"2009-02-19T14:57:15Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Feb 19, 2009 at 05:20:53AM -0500, Jeff King wrote:\n> > Yes, I do the same. But notice that you did \"git rebase -i -- \n> > >>>origin<<<---\". Seems to me you are definitely _thinking_ in terms of \n> > your topic _branch_ and not in terms of \"the last few commits\".\n> \n> Perhaps. I think of it as \"the set of commits not yet published\"\n> (since I publish only by sending patches to Junio, and he is my origin)\n> and nothing to do with the topic branch itself.\n\nIndeed, I bet most people who use this workflow think of git rebase -i\norigin or \"git rebase -i HEAD^^^^\" (where I normally figure out how\nmany commits I need to go back and type the right number of carets) as\na magic command that does what we want, without necessarily thinking\nabout why it works the way that it does.\n\nI can guarantee that most of the time I don't think \"hmm, so I'm going\nto be rebasing my topic branch onto origin so I can make some\nchanges.\" Nope, it's, \"I'm going to futz with the commits to get them\njust right\".\n\n \t \t \t \t - Ted\n"},{"id":"105477","messageId":"499D84E8.1020505@xiplink.com","threadId":"17896","inReplyTo":"7v63j6oi0d.fsf@gitster.siamese.dyndns.org","subject":"Re: git rebase -i","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2009-02-19T16:12:24Z","receivedAt":"2009-02-19T16:12:24Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Junio C Hamano wrote:\n> \n>> I'd prefer something a bit less arbitrary, like using the tracked head\n>> for a tracking branch.\n> \n> I'd say that might be a very sane default for users or \"branch --track\"\n> and/or \"pull --rebase\", both for i-rebase and rebase.\n\nThat'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.\n\n\t\tM.\n"},{"id":"105486","messageId":"544dda350902190953w6a3fc71br3235b7aa84933598@mail.gmail.com","threadId":"17896","inReplyTo":"499D84E8.1020505@xiplink.com","subject":"Re: git rebase -i","fromName":"Nazri Ramliy","fromEmail":"ayiehere@gmail.com","sentAt":"2009-02-19T17:53:56Z","receivedAt":"2009-02-19T17:53:56Z","isPatch":false,"sender":{"key":"ayiehere@gmail.com","avatar":"https://avatars.githubusercontent.com/u/164756?v=4"},"body":"I think it's about time to put this bikeshed argument to rest.\n\n*ducks*\n\nnazri.\n"},{"id":"105514","messageId":"76718490902191255w24b30bd8jacaed8aa919d6526@mail.gmail.com","threadId":"17896","inReplyTo":"43d8ce650902190121v2e18aac1rfaa64a4ce6e799a3@mail.gmail.com","subject":"Re: git rebase -i","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-19T20:55:03Z","receivedAt":"2009-02-19T20:55:03Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Thu, Feb 19, 2009 at 4:21 AM, John Tapsell wrote:\n> Hi,\n>\n> I often do 'git rebase -i HEAD~10' to rebase. Since afaics it\n> doesn't matter if you go back 'too far' I just always use HEAD~10 even\n> if it's just for the last or so commit.\n>\n> Would there be any objections to making 'git rebase -i' default to\n> HEAD~10 or maybe 16 or 20. Having sensible defaults for commands\n> helps a bit with making it easier to use.\n\nI think the following might be reasonable to support:\n\n$ git rebase -i -10\n$ git rebase -i -n -10\n\nj.\n"},{"id":"105515","messageId":"alpine.DEB.1.00.0902192203280.6223@intel-tinevez-2-302","threadId":"17896","inReplyTo":"76718490902191255w24b30bd8jacaed8aa919d6526@mail.gmail.com","subject":"Re: git rebase -i","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-19T21:04:58Z","receivedAt":"2009-02-19T21:04:58Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 19 Feb 2009, Jay Soffian wrote:\n\n> On Thu, Feb 19, 2009 at 4:21 AM, John Tapsell wrote:\n>\n> > I often do 'git rebase -i HEAD~10' to rebase. Since afaics it \n> > doesn't matter if you go back 'too far' I just always use HEAD~10 even \n> > if it's just for the last or so commit.\n> >\n> > Would there be any objections to making 'git rebase -i' default to \n> > HEAD~10 or maybe 16 or 20. Having sensible defaults for commands \n> > helps a bit with making it easier to use.\n> \n> I think the following might be reasonable to support:\n> \n> $ git rebase -i -10\n> $ git rebase -i -n -10\n\nI disagree.\n\nYou think -10 would be the same as HEAD~10? Think again. And include \nmerge commits amongst the last 9 commits in your thoughts.\n\nOnce you thought about such a scenario, \"-10\" is probably no longer that \nattractive, right?\n\nCiao,\nDscho\n"},{"id":"105516","messageId":"76718490902191307h39e4dd02nafb8ef02d670dc57@mail.gmail.com","threadId":"17896","inReplyTo":"alpine.DEB.1.00.0902192203280.6223@intel-tinevez-2-302","subject":"Re: git rebase -i","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-19T21:07:32Z","receivedAt":"2009-02-19T21:07:32Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Thu, Feb 19, 2009 at 4:04 PM, Johannes Schindelin\n wrote:\n> You think -10 would be the same as HEAD~10?\n\nI think it would mean the same thing to rebase as it does to format-patch.\n\nI will now admit I haven't thought about what it means to format-patch\nif there are merges. :-)\n\nj.\n"},{"id":"105529","messageId":"gnkre1$g8s$1@ger.gmane.org","threadId":"17896","inReplyTo":"76718490902191255w24b30bd8jacaed8aa919d6526@mail.gmail.com","subject":"Re: git rebase -i","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2009-02-19T23:53:37Z","receivedAt":"2009-02-19T23:53:37Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Thursday 19 February 2009 21:55, Jay Soffian wrote:\n\n> On Thu, Feb 19, 2009 at 4:21 AM, John Tapsell wrote:\n>> Hi,\n>>\n>> I often do 'git rebase -i HEAD~10' to rebase. Since afaics it\n>> doesn't matter if you go back 'too far' I just always use HEAD~10 even\n>> if it's just for the last or so commit.\n>>\n>> Would there be any objections to making 'git rebase -i' default to\n>> HEAD~10 or maybe 16 or 20. Having sensible defaults for commands\n>> helps a bit with making it easier to use.\n> \n> I think the following might be reasonable to support:\n> \n> $ git rebase -i -10\n> $ git rebase -i -n -10\n\nThis feature gets my vote. I actually gave the implementation a quick try,\nbut didn't get very far through it. I was actually considering making git\nrev-parse support the syntax.\n\nYes, as remarked by Johannes there are issue when there are merges in between\n(in which case -10 is most likely not the same as HEAD~10), but I would say\nthat this is in no way a good reason to deprive users from the comfort it can\ngive in most common situations.\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"105530","messageId":"alpine.DEB.1.00.0902200105520.10279@pacific.mpi-cbg.de","threadId":"17896","inReplyTo":"gnkre1$g8s$1@ger.gmane.org","subject":"Re: git rebase -i","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-20T00:07:57Z","receivedAt":"2009-02-20T00:07:57Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 20 Feb 2009, Giuseppe Bilotta wrote:\n\n> On Thursday 19 February 2009 21:55, Jay Soffian wrote:\n> \n> > On Thu, Feb 19, 2009 at 4:21 AM, John Tapsell wrote:\n> >> Hi,\n> >>\n> >> I often do 'git rebase -i HEAD~10' to rebase. Since afaics it\n> >> doesn't matter if you go back 'too far' I just always use HEAD~10 even\n> >> if it's just for the last or so commit.\n> >>\n> >> Would there be any objections to making 'git rebase -i' default to\n> >> HEAD~10 or maybe 16 or 20. Having sensible defaults for commands\n> >> helps a bit with making it easier to use.\n> > \n> > I think the following might be reasonable to support:\n> > \n> > $ git rebase -i -10\n> > $ git rebase -i -n -10\n> \n> This feature gets my vote. I actually gave the implementation a quick try,\n> but didn't get very far through it. I was actually considering making git\n> rev-parse support the syntax.\n> \n> Yes, as remarked by Johannes there are issue when there are merges in between\n> (in which case -10 is most likely not the same as HEAD~10), but I would say\n> that this is in no way a good reason to deprive users from the comfort it can\n> give in most common situations.\n\n\"I want it, I want it, I want it, and I'll just ignore what you just said\" \nis not a good counterargument, would you say?\n\nSure, you even cited me, responding to the mail I responded to (as opposed \nto my mail), but you managed to ignore my argument nevertheless.\n\nCiao,\nDscho\n"},{"id":"105533","messageId":"7vzlgij7cb.fsf@gitster.siamese.dyndns.org","threadId":"17896","inReplyTo":"76718490902191255w24b30bd8jacaed8aa919d6526@mail.gmail.com","subject":"Re: git rebase -i","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-20T00:11:00Z","receivedAt":"2009-02-20T00:11:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jay Soffian writes:\n\n> On Thu, Feb 19, 2009 at 4:21 AM, John Tapsell wrote:\n>> Hi,\n>>\n>> I often do 'git rebase -i HEAD~10' to rebase. Since afaics it\n>> doesn't matter if you go back 'too far' I just always use HEAD~10 even\n>> if it's just for the last or so commit.\n>>\n>> Would there be any objections to making 'git rebase -i' default to\n>> HEAD~10 or maybe 16 or 20. Having sensible defaults for commands\n>> helps a bit with making it easier to use.\n>\n> I think the following might be reasonable to support:\n>\n> $ git rebase -i -10\n> $ git rebase -i -n -10\n\nThe syntax would certainly imply a different semantics from giving\nHEAD~10. How would you compute the set of commits to rebase sanely when\nyou have merges after your 10th direct parent commit?\n"},{"id":"105535","messageId":"76718490902191626u2202ed38xf63111b6a2758206@mail.gmail.com","threadId":"17896","inReplyTo":"7vzlgij7cb.fsf@gitster.siamese.dyndns.org","subject":"Re: git rebase -i","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-20T00:26:23Z","receivedAt":"2009-02-20T00:26:23Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Thu, Feb 19, 2009 at 7:11 PM, Junio C Hamano wrote:\n\n>> $ git rebase -i -10\n>> $ git rebase -i -n -10\n>\n> The syntax would certainly imply a different semantics from giving\n> HEAD~10. How would you compute the set of commits to rebase sanely when\n> you have merges after your 10th direct parent commit?\n\nI didn't mean to suggest that -10 and HEAD~10 are the same thing.\n\nI would expect -10 to act the same when given to rebase as it does\nwhen given to format-patch. In both cases, you are asking the command\nfor a set of commits.\n\nBut as I said, I don't exactly know what -10 means to format-patch if\nthere are merge commits because I've never tried to use it in such a\ncontext.\n\nj.\n"},{"id":"105600","messageId":"499E8DB9.5030505@drmicha.warpmail.net","threadId":"17896","inReplyTo":"76718490902191626u2202ed38xf63111b6a2758206@mail.gmail.com","subject":"Re: git rebase -i","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-02-20T11:02:17Z","receivedAt":"2009-02-20T11:02:17Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jay Soffian venit, vidit, dixit 20.02.2009 01:26:\n> On Thu, Feb 19, 2009 at 7:11 PM, Junio C Hamano wrote:\n> \n>>> $ git rebase -i -10\n>>> $ git rebase -i -n -10\n>> The syntax would certainly imply a different semantics from giving\n>> HEAD~10. How would you compute the set of commits to rebase sanely when\n>> you have merges after your 10th direct parent commit?\n> \n> I didn't mean to suggest that -10 and HEAD~10 are the same thing.\n> \n> I would expect -10 to act the same when given to rebase as it does\n> when given to format-patch. In both cases, you are asking the command\n> for a set of commits.\n> \n> But as I said, I don't exactly know what -10 means to format-patch if\n> there are merge commits because I've never tried to use it in such a\n> context.\n> \n> j.\n\nI guess it means exactly what\n\ngit rev-list -10 HEAD\n\nmeans. And that would also be the easy way to implement it.\n\nBUT: The fact that it's not obvious what \"-10\" is in non-linear\nsituations is the reason why it's probably not a good idea for r-b-i. If\nyou want to rebase you need a clear picture of the revision graph. If\nyou have one you know where to rebase from, and how to say so using\nHEAD~5 and such. If you don't have one then using an option like -10\ncould be dangerous. And in a linear situation, -10 is equivalent to\nHEAD~10 (+-1 ...).\n\nMichael\n"},{"id":"105831","messageId":"20090223003245.GC21616@leksak.fem-net","threadId":"17896","inReplyTo":"43d8ce650902190152t6162593x8d0920be0e6d7a6d@mail.gmail.com","subject":"Re: git rebase -i","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2009-02-23T00:32:45Z","receivedAt":"2009-02-23T00:32:45Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\n> > I think it's better to use aliases for this kind of personal things:\n> >\n> > git config --global alias.my-rebase \"rebase -i HEAD~10\"\n> >\n> > Now you can do:\n> >\n> > git my-rebase\n> >\n> \n> I'm trying to make git more obvious and easier to use, rather than\n> find any solution :-)\n\nAs Wincent pointed out, git rebase -i without arguments isn't that\nobvious or intuitive.\n\nIf you was looking for a solution, I'd be telling you that I use a\nsimple script \"git-tickle-last\" for this purpose:\n\n--- 8< ---\n#!/bin/sh\ndefault=10\n\nget_safe_num () {\n\tn=0\n\tgit rev-list --parents \"HEAD~$default..\" | while read line\n\tdo\n\t\ti=0\n\t\tfor p in $line\n\t\tdo\n\t\t\ti=$((i+1))\n\t\tdone\n\t\tif test \"$i\" -gt 2\n\t\tthen\n\t\t\techo $n\n\t\t\treturn 1\n\t\tfi\n\t\tn=$((n+1))\n\tdone && echo $default\n}\n\ngit rebase -i \"HEAD~$(get_safe_num)\"\n--- >8---\n\nIt makes sure (I hope) that no merges get into the list, but it doesn't\ncare about published changes (i.e. tracking branch behavior).\n\nI use it because I often reorder or squash commits before I push or\nmerge.\n\nRegards,\n Stephan\n\n-- \nStephan Beyer , PGP 0x6EDDD207FCC5040F\n"}]}