{"thread":{"id":"23398","subject":"[BUG] - git rebase -i performs rebase when it shouldn't?","startedAt":"2010-04-09T19:35:42Z","lastAt":"2010-04-14T06:08:19Z","messageCount":19,"participants":["Eugene Sajine","Jeff King","Junio C Hamano","Johannes Sixt","Michal Vitecek"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"139068","messageId":"z2q76c5b8581004091235ucd9b2a52i223b3191b288c42a@mail.gmail.com","threadId":"23398","inReplyTo":null,"subject":"[BUG] - git rebase -i performs rebase when it shouldn't?","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-04-09T19:35:42Z","receivedAt":"2010-04-09T19:35:42Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"Hi,\n\n\nIn case of this situation\n\n       A  master\n        \\\n         B  next\n          \\\n           C  topic\n\n\n$ git rebase --onto master topic\nFirst, rewinding head to replay your work on top of it...\nfatal: Not a range.\nNothing to do.\n\nWhich is OK.\n\nWhen I fired up interactive rebase, it printed me “noop”, so I was\nexpecting it to do nothing and exited the vi, without deleting this\n\"noop\". But it did performed some operation and I actually have commit\nC lost, with topic pointing to the same commit as master.\n\n$ git rebase -i --onto master topic\nSuccessfully rebased and updated refs/heads/topic.\n\nI believe this is wrong.\n\n\nThanks,\nEugene\n"},{"id":"139105","messageId":"20100410042609.GA24295@coredump.intra.peff.net","threadId":"23398","inReplyTo":"z2q76c5b8581004091235ucd9b2a52i223b3191b288c42a@mail.gmail.com","subject":"Re: [BUG] - git rebase -i performs rebase when it shouldn't?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-04-10T04:26:09Z","receivedAt":"2010-04-10T04:26:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 09, 2010 at 03:35:42PM -0400, Eugene Sajine wrote:\n\n> In case of this situation\n> \n>        A  master\n>         \\\n>          B  next\n>           \\\n>            C  topic\n> \n> \n> $ git rebase --onto master topic\n> First, rewinding head to replay your work on top of it...\n> fatal: Not a range.\n> Nothing to do.\n> \n> Which is OK.\n\nI think this doesn't do quite what you thought. It's true there is\n\"nothing to do\" as in \"nothing to apply\", but it _did_ in fact rewind\ntopic back to \"master\".\n\nYou seem to be thinking that\n\n git rebase --onto master topic\n\nmeans \"rebase everything from master to topic onto master\". It doesn't.\nThat would be:\n\n git rebase master topic\n\nor, if you are already on topic, just\n\n git rebase master\n\nThe \"--onto\" option takes an argument, which says \"put the commits on\ntop of here, even though it was not the upstream base otherwise\nspecified\". So what your command does is say \"using the current branch\n(which is topic), take everything built on top of topic (which is\nnothing), and rebuild it on top of master\".\n\nSo no, it's not a bug. Yes, it's a terrible interface. There is really\nno reason IMHO for rebase to take a \"which branch to operate on\"\nargument at all. It should just operate on HEAD, like merge does. If you\nwant to merge on a different branch, you \"git checkout\" that branch\nfirst.\n\nThat would have made your error less likely, because you would have had\nno reason to think you needed to say \"topic\" at all.\n\n-Peff\n"},{"id":"139107","messageId":"7vsk73zzt1.fsf@alter.siamese.dyndns.org","threadId":"23398","inReplyTo":"20100410042609.GA24295@coredump.intra.peff.net","subject":"Re: [BUG] - git rebase -i performs rebase when it shouldn't?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-10T04:39:22Z","receivedAt":"2010-04-10T04:39:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> So no, it's not a bug. Yes, it's a terrible interface. There is really\n> no reason IMHO for rebase to take a \"which branch to operate on\"\n> argument at all. It should just operate on HEAD, like merge does. If you\n> want to merge on a different branch, you \"git checkout\" that branch\n> first.\n\nI guess it's my turn to say \"sorry it was my fault made in pre-maintainer\ndays around 59e6b23 ([PATCH] git-rebase-script: rebase local commits to\nnew upstream head., 2005-06-25).\n\nI used to religiously rebase slushy topics that are not in any stable\nintegration branches (we used to have only 'master' and 'pu'), and\n\n\tgit rebase master foo\n git rebase master bar\n git rebase master baz\n\nwas far easier to type than\n\n\tgit checkout foo && git rebase master\n\tgit checkout bar && git rebase master\n\tgit checkout baz && git rebase master\n\nwhen you have many topics. Especially because the exact keystroke\nsequences are:\n\n\tgit rebase master foo ENTER\n\t^P (recall the last line) ^W (delete the last word) bar ENTER\n\t^P ^W baz ENTER\n\nfor the former. Of course, I can do the same with the latter interface\n\n\tsh -c 'git checkout \"$1\" && git rebase master' - foo ENTER\n\t^P (recall the last line) ^W (delete the last word) bar ENTER\n\t^P ^W baz ENTER\n\nso that is not a very good excuse, but at least now people know where it\ncame from ;-)\n"},{"id":"139109","messageId":"20100410044730.GB24295@coredump.intra.peff.net","threadId":"23398","inReplyTo":"7vsk73zzt1.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] - git rebase -i performs rebase when it shouldn't?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-04-10T04:47:30Z","receivedAt":"2010-04-10T04:47:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 09, 2010 at 09:39:22PM -0700, Junio C Hamano wrote:\n\n> I used to religiously rebase slushy topics that are not in any stable\n> integration branches (we used to have only 'master' and 'pu'), and\n> \n> \tgit rebase master foo\n> git rebase master bar\n> git rebase master baz\n> \n> was far easier to type than\n> \n> \tgit checkout foo && git rebase master\n> \tgit checkout bar && git rebase master\n> \tgit checkout baz && git rebase master\n\nInterestingly, I faced a similar problem a few months ago. I have many\nhalf-finished topics, and I aggressively rebase them against master\n(mostly to see and fix conflicts early). But I wrote a script so I don't\nhave to type each one individually. :)\n\nIt uses for-each-ref with a filter to get the list of topics, and then\nrebases in a loop. It just barfs when a rebase has conflicts, which is\nOK. You fix them, finish the rebase, and restart the script, which just\nskips over the noop rebases. Eventually it finishes successfully.\n\n-Peff\n"},{"id":"139191","messageId":"4BC0D87E.70001@kdbg.org","threadId":"23398","inReplyTo":"7vsk73zzt1.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] - git rebase -i performs rebase when it shouldn't?","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2010-04-10T19:58:54Z","receivedAt":"2010-04-10T19:58:54Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 10.04.2010 06:39, schrieb Junio C Hamano:\n> I used to religiously rebase slushy topics that are not in any stable\n> integration branches (we used to have only 'master' and 'pu'), and\n>\n> \tgit rebase master foo\n> git rebase master bar\n> git rebase master baz\n>\n> was far easier to type than\n>\n> \tgit checkout foo&& git rebase master\n> \tgit checkout bar&& git rebase master\n> \tgit checkout baz&& git rebase master\n\nI'm actually very glad that the current interface is the way it is - \nbecause it can do the rebase *without* the checkout. This way you can save \na lot of recompilation due to changed timestamps if the topic is based on \nan old version.\n\nOnly that some (all?) variants of rebase still unnecessarily do the \ncheckout...\n\nOh, and it would naturally extend to a master..topic syntax.\n\n-- Hannes\n"},{"id":"139205","messageId":"h2x76c5b8581004101510hc1d15f42u7e48dafbc275c998@mail.gmail.com","threadId":"23398","inReplyTo":"20100410042609.GA24295@coredump.intra.peff.net","subject":"Re: [BUG] - git rebase -i performs rebase when it shouldn't?","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-04-10T22:10:53Z","receivedAt":"2010-04-10T22:10:53Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"On Sat, Apr 10, 2010 at 12:26 AM, Jeff King wrote:\n> On Fri, Apr 09, 2010 at 03:35:42PM -0400, Eugene Sajine wrote:\n>\n>> In case of this situation\n>>\n>>        A  master\n>>         \\\n>>          B  next\n>>           \\\n>>            C  topic\n>>\n>>\n>> $ git rebase --onto master topic\n>> First, rewinding head to replay your work on top of it...\n>> fatal: Not a range.\n>> Nothing to do.\n>>\n>> Which is OK.\n>\n> I think this doesn't do quite what you thought. It's true there is\n> \"nothing to do\" as in \"nothing to apply\", but it _did_ in fact rewind\n> topic back to \"master\".\n>\n> You seem to be thinking that\n>\n>  git rebase --onto master topic\n>\n> means \"rebase everything from master to topic onto master\". It doesn't.\n> That would be:\n>\n>  git rebase master topic\n>\n> or, if you are already on topic, just\n>\n>  git rebase master.\n>\n> The \"--onto\" option takes an argument, which says \"put the commits on\n> top of here, even though it was not the upstream base otherwise\n> specified\". So what your command does is say \"using the current branch\n> (which is topic), take everything built on top of topic (which is\n> nothing), and rebuild it on top of master\".\n\nActually no, i was not thinking about what you think i was;). What i\nwas trying to understand with this command (git rebase --onto master\ntopic) is the\nbehavior of the system when the topic branch is indirect descendant of\nthe master and the direct parent of topic (next) is omitted, skipped.\n\nIn this situatiion\n\ngit rebase master topic\n\ndoes not work (see thread \"git rebase command and docs questions\") p1.\n\nSo, once again i think that the interface in this case worked properly:\n\nas topic is not direct descendant, master option value goes to --onto\nand there is no range defined properly.\nTherefore the command worked ok, when it refused to do anything.\n\nNow the problem i have is that:\n\ngit rebase -i --onto master topic\n\nactually worked and did something, what i would not expect it to do.\n\nSo, the problem is: non-interactive rebase DOES NOT execute the\ncommand, interactive DOES execute.\n\n>\n> So no, it's not a bug. Yes, it's a terrible interface. There is really\n> no reason IMHO for rebase to take a \"which branch to operate on\"\n> argument at all. It should just operate on HEAD, like merge does. If you\n> want to merge on a different branch, you \"git checkout\" that branch\n> first.\n\nThe bug is in the fact that rebase works differently in interactive\nand non-interactive variants.\n\nThanks,\nEugene\n"},{"id":"139238","messageId":"20100411101526.GA20484@coredump.intra.peff.net","threadId":"23398","inReplyTo":"4BC0D87E.70001@kdbg.org","subject":"Re: [BUG] - git rebase -i performs rebase when it shouldn't?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-04-11T10:15:26Z","receivedAt":"2010-04-11T10:15:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Apr 10, 2010 at 09:58:54PM +0200, Johannes Sixt wrote:\n\n> >\tgit checkout foo&& git rebase master\n> >\tgit checkout bar&& git rebase master\n> >\tgit checkout baz&& git rebase master\n> \n> I'm actually very glad that the current interface is the way it is -\n> because it can do the rebase *without* the checkout. This way you can\n> save a lot of recompilation due to changed timestamps if the topic is\n> based on an old version.\n> \n> Only that some (all?) variants of rebase still unnecessarily do the\n> checkout...\n\nGood point. Originally, we did the rebase directly on the branch, though\nI'm not sure if we did \"checkout $branch && reset $onto\" or \"branch -f\n$branch $onto && checkout $branch\". These days we operate on a detached\nHEAD, and we seem to \"checkout $onto^0\", which should do the\noptimization you mention.\n\n-Peff\n"},{"id":"139239","messageId":"20100411102255.GB20484@coredump.intra.peff.net","threadId":"23398","inReplyTo":"h2x76c5b8581004101510hc1d15f42u7e48dafbc275c998@mail.gmail.com","subject":"Re: [BUG] - git rebase -i performs rebase when it shouldn't?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-04-11T10:22:55Z","receivedAt":"2010-04-11T10:22:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Apr 10, 2010 at 06:10:53PM -0400, Eugene Sajine wrote:\n\n> Actually no, i was not thinking about what you think i was;). What i\n> was trying to understand with this command (git rebase --onto master\n> topic) is the behavior of the system when the topic branch is indirect\n> descendant of the master and the direct parent of topic (next) is\n> omitted, skipped.\n\nBut in \"git rebase --onto master topic\", the relationship between master\nand topic is irrelevant. It is the same as:\n\n git rebase --onto master topic HEAD\n\nwhich will consider the range between topic and HEAD as the set of\ncommits to rebase.\n\nDid you want to do:\n\n git rebase --onto master next topic\n\n? That would take the commits between next and topic (i.e., just \"topic\"\nin your example), and rebuild them on top of master.\n\n> Now the problem i have is that:\n> \n> git rebase -i --onto master topic\n> \n> actually worked and did something, what i would not expect it to do.\n> \n> So, the problem is: non-interactive rebase DOES NOT execute the\n> command, interactive DOES execute.\n\nThat's not the result I get. The non-interactive rebase _does_ do the\nsame thing. Try this:\n\n mkdir repo\n cd repo\n git init\n\n echo content >>file && git add file && git commit -m one\n git checkout -b next\n echo content >>file && git add file && git commit -m two\n git checkout -b topic\n echo content >>file && git add file && git commit -m three\n\n git rebase --onto master topic\n\nYou will see that \"topic\" has been reset back to commit one, the same as\nmaster.\n\nIf that was not happening before, it was likely because you were not\nactually on the \"topic\" branch before. So who knows what the implicit\n\"HEAD\" argument referred to.\n\n> The bug is in the fact that rebase works differently in interactive\n> and non-interactive variants.\n\nI don't think it does, as shown by my example above. If you still think\nso, please create a short test case that demonstrates the difference.\n\n-Peff\n"},{"id":"139252","messageId":"y2s76c5b8581004110706p7b63900aqf90f9c1462a1f637@mail.gmail.com","threadId":"23398","inReplyTo":"20100411102255.GB20484@coredump.intra.peff.net","subject":"Re: [BUG] - git rebase -i performs rebase when it shouldn't?","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-04-11T14:06:00Z","receivedAt":"2010-04-11T14:06:00Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"I got your point about the HEAD which is by default get's added to the\nend of the command, so it becomes\n\ngit rebase --onto master topic HEAD\n\nI will think about it it more.\n\nI'm pretty sure that i was surprised by the fact that i've got\ndifferent behavior in interactive and non-interactive variants, but i\nwill recheck.\n\nI forgot to mention it was in windows version of git.\nI will try to provide the printout of my actions tomorrow when i will\nget to this machine.\n\nThanks a lot,\nEugene\n\nOn Sun, Apr 11, 2010 at 6:22 AM, Jeff King wrote:\n> On Sat, Apr 10, 2010 at 06:10:53PM -0400, Eugene Sajine wrote:\n>\n>> Actually no, i was not thinking about what you think i was;). What i\n>> was trying to understand with this command (git rebase --onto master\n>> topic) is the behavior of the system when the topic branch is indirect\n>> descendant of the master and the direct parent of topic (next) is\n>> omitted, skipped.\n>\n> But in \"git rebase --onto master topic\", the relationship between master\n> and topic is irrelevant. It is the same as:\n>\n>  git rebase --onto master topic HEAD\n>\n> which will consider the range between topic and HEAD as the set of\n> commits to rebase.\n>\n> Did you want to do:\n>\n>  git rebase --onto master next topic\n>\n> ? That would take the commits between next and topic (i.e., just \"topic\"\n> in your example), and rebuild them on top of master.\n>\n>> Now the problem i have is that:\n>>\n>> git rebase -i --onto master topic\n>>\n>> actually worked and did something, what i would not expect it to do.\n>>\n>> So, the problem is: non-interactive rebase DOES NOT execute the\n>> command, interactive DOES execute.\n>\n> That's not the result I get. The non-interactive rebase _does_ do the\n> same thing. Try this:\n>\n>  mkdir repo\n>  cd repo\n>  git init\n>\n>  echo content >>file && git add file && git commit -m one\n>  git checkout -b next\n>  echo content >>file && git add file && git commit -m two\n>  git checkout -b topic\n>  echo content >>file && git add file && git commit -m three\n>\n>  git rebase --onto master topic\n>\n> You will see that \"topic\" has been reset back to commit one, the same as\n> master.\n>\n> If that was not happening before, it was likely because you were not\n> actually on the \"topic\" branch before. So who knows what the implicit\n> \"HEAD\" argument referred to.\n>\n>> The bug is in the fact that rebase works differently in interactive\n>> and non-interactive variants.\n>\n> I don't think it does, as shown by my example above. If you still think\n> so, please create a short test case that demonstrates the difference.\n>\n> -Peff\n>\n"},{"id":"139273","messageId":"201004111954.38156.j6t@kdbg.org","threadId":"23398","inReplyTo":"20100411101526.GA20484@coredump.intra.peff.net","subject":"Re: [BUG] - git rebase -i performs rebase when it shouldn't?","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2010-04-11T17:54:37Z","receivedAt":"2010-04-11T17:54:37Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Sonntag, 11. April 2010, Jeff King wrote:\n> Good point. Originally, we did the rebase directly on the branch, though\n> I'm not sure if we did \"checkout $branch && reset $onto\" or \"branch -f\n> $branch $onto && checkout $branch\". These days we operate on a detached\n> HEAD, and we seem to \"checkout $onto^0\", which should do the\n> optimization you mention.\n\nBut before this \"checkout $onto^0\" happens, some (all?) variants still \ndo \"checkout topic && rev-list upstream..HEAD\" instead of just \"rev-list \nupstream..topic\".\n\n-- Hannes\n"},{"id":"139304","messageId":"20100412010123.GA11051@coredump.intra.peff.net","threadId":"23398","inReplyTo":"201004111954.38156.j6t@kdbg.org","subject":"Re: [BUG] - git rebase -i performs rebase when it shouldn't?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-04-12T01:01:23Z","receivedAt":"2010-04-12T01:01:23Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Apr 11, 2010 at 07:54:37PM +0200, Johannes Sixt wrote:\n\n> On Sonntag, 11. April 2010, Jeff King wrote:\n> > Good point. Originally, we did the rebase directly on the branch, though\n> > I'm not sure if we did \"checkout $branch && reset $onto\" or \"branch -f\n> > $branch $onto && checkout $branch\". These days we operate on a detached\n> > HEAD, and we seem to \"checkout $onto^0\", which should do the\n> > optimization you mention.\n> \n> But before this \"checkout $onto^0\" happens, some (all?) variants still \n> do \"checkout topic && rev-list upstream..HEAD\" instead of just \"rev-list \n> upstream..topic\".\n\nI don't think this is the case any longer for regular rebase, from my\nreading of the code and doing a rebase under GIT_TRACE. Grepping the\nhistory turns up 0cb0664 (rebase [--onto O] A B: omit needless checkout,\n2008-03-15).\n\nBut doing an interactive rebase under GIT_TRACE, it looks like it still\ndoes the unnecessary checkout.\n\n-Peff\n"},{"id":"139324","messageId":"20100412105034.GC30605@mageo.cz","threadId":"23398","inReplyTo":"4BC0D87E.70001@kdbg.org","subject":"Re: [BUG] - git rebase -i performs rebase when it shouldn't?","fromName":"Michal Vitecek","fromEmail":"fuf@mageo.cz","sentAt":"2010-04-12T10:50:34Z","receivedAt":"2010-04-12T10:50:34Z","isPatch":false,"sender":{"key":"fuf@mageo.cz","avatar":null},"body":"On 10.04.2010 21:58 CEST, Johannes Sixt wrote:\n>Am 10.04.2010 06:39, schrieb Junio C Hamano:\n>>I used to religiously rebase slushy topics that are not in any stable\n>>integration branches (we used to have only 'master' and 'pu'), and\n>>\n>>\tgit rebase master foo\n>> git rebase master bar\n>> git rebase master baz\n>>\n>>was far easier to type than\n>>\n>>\tgit checkout foo&& git rebase master\n>>\tgit checkout bar&& git rebase master\n>>\tgit checkout baz&& git rebase master\n>\n>I'm actually very glad that the current interface is the way it is -\n>because it can do the rebase *without* the checkout. This way you can\n>save a lot of recompilation due to changed timestamps if the topic is\n>based on an old version.\n>\n>Only that some (all?) variants of rebase still unnecessarily do the\n>checkout...\n\n Is there any chance for merge to behave the same? I really like that I\n don't have to do a checkout prior rebasing.\n\n Thanks,\n-- \n\t\tMichal Vitecek\t\t(fuf@mageo.cz)\n"},{"id":"139332","messageId":"q2z76c5b8581004120709t860ff112i5dd057327b94ad0e@mail.gmail.com","threadId":"23398","inReplyTo":"y2s76c5b8581004110706p7b63900aqf90f9c1462a1f637@mail.gmail.com","subject":"Re: [BUG] - git rebase -i performs rebase when it shouldn't?","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-04-12T14:09:42Z","receivedAt":"2010-04-12T14:09:42Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"On Sun, Apr 11, 2010 at 10:06 AM, Eugene Sajine wrote:\n> I got your point about the HEAD which is by default get's added to the\n> end of the command, so it becomes\n>\n> git rebase --onto master topic HEAD\n>\n> I will think about it it more.\n>\n> I'm pretty sure that i was surprised by the fact that i've got\n> different behavior in interactive and non-interactive variants, but i\n> will recheck.\n>\n> I forgot to mention it was in windows version of git.\n> I will try to provide the printout of my actions tomorrow when i will\n> get to this machine.\n>\n> Thanks a lot,\n> Eugene\n\n\nHere is the printout of my actions with some comments:\n\nesajine@ESAJINEWWW /c/git_repos\n$ mkdir test2; cd test2; git init; echo \"initial\" > 1.txt; git add .;\ngit commit -m \"initial commit\"; git checkout -b next; echo \"commit\nfrom next\" > 2.txt; git add .; git commit -m \"commit from next\"; git\ncheckout -b topic; echo \"commit from topic\" > 3.txt; git add .; git\ncommit -m \"commit from topic\"\nInitialized empty Git repository in c:/git_repos/test2/.git/\nwarning: LF will be replaced by CRLF in 1.txt\n[master (root-commit) 89c5353] initial commit\nwarning: LF will be replaced by CRLF in 1.txt\n1 files changed, 1 insertions(+), 0 deletions(-)\ncreate mode 100644 1.txt\nSwitched to a new branch 'next'\nwarning: LF will be replaced by CRLF in 1.txt\nwarning: LF will be replaced by CRLF in 2.txt\n[next cec1eeb] commit from next\nwarning: LF will be replaced by CRLF in 2.txt\n1 files changed, 1 insertions(+), 0 deletions(-)\ncreate mode 100644 2.txt\nSwitched to a new branch 'topic'\nwarning: LF will be replaced by CRLF in 1.txt\nwarning: LF will be replaced by CRLF in 2.txt\nwarning: LF will be replaced by CRLF in 3.txt\n[topic 9975772] commit from topic\nwarning: LF will be replaced by CRLF in 3.txt\n1 files changed, 1 insertions(+), 0 deletions(-)\ncreate mode 100644 3.txt\n\nesajine@ESAJINEWWW /c/git_repos/test2 (topic)\n$ pwd\n/c/git_repos/test2\n\nesajine@ESAJINEWWW /c/git_repos/test2 (topic)\n$ git status\n# On branch topic\nnothing to commit (working directory clean)\n\nesajine@ESAJINEWWW /c/git_repos/test2 (topic)\n$ git log\ncommit 9975772c641c438a0a77932c18c159e9551706ce\nAuthor: Eugene Sajine \nDate:   Fri Apr 9 13:04:24 2010 -0400\n\n   commit from topic\n\ncommit cec1eebc8db042b1b8a1002b07767eac56884126\nAuthor: Eugene Sajine \nDate:   Fri Apr 9 13:04:24 2010 -0400\n\n   commit from next\n\ncommit 89c5353c9b0cfc476b323db11565ea210341469a\nAuthor: Eugene Sajine \nDate:   Fri Apr 9 13:04:24 2010 -0400\n\n   initial commit\n\nesajine@ESAJINEWWW /c/git_repos/test2 (topic)\n$ git rebase master\nCurrent branch topic is up to date.\n<======= Really? Topic is actually based on next – what does this \"up\nto date\" mean??\n\nesajine@ESAJINEWWW /c/git_repos/test2 (topic)\n$ git rebase --onto master topic\nFirst, rewinding head to replay your work on top of it...\nfatal: Not a range.\nNothing to do.\n                <======== topic..HEAD is not a range, agreed\n\nesajine@ESAJINEWWW /c/git_repos/test2 (topic)\n$ git rebase --onto master\nfatal: Needed a single revision\ninvalid upstream\n              <========= fine\n\nesajine@ESAJINEWWW /c/git_repos/test2 (topic)\n$ git rebase --onto master next..topic\nfatal: Needed a single revision\ninvalid upstream next..topic\n    <======== strange that this notation is not supported, considering\nerror above about the range\n\nesajine@ESAJINEWWW /c/git_repos/test2 (topic)\n$ git rebase -i --onto master topic\nSuccessfully rebased and updated refs/heads/topic. <=== BUG – here it\nprinted me “noop” in file to edit, when I exited it should do nothing,\nbut it still did something and I double checked it.\n\nesajine@ESAJINEWWW /c/git_repos/test2 (topic)\n$ git rebase --onto master topic\nCurrent branch topic is up to date.\n\nesajine@ESAJINEWWW /c/git_repos/test2 (topic)\n$ git log\ncommit 89c5353c9b0cfc476b323db11565ea210341469a\nAuthor: Eugene Sajine \nDate:   Fri Apr 9 13:04:24 2010 -0400\n\n   initial commit\n        <====== topic now points to master, last commit from topic is\nlost\n\nesajine@ESAJINEWWW /c/git_repos\n$ git version\ngit version 1.6.4.msysgit.0\n\nThanks,\nEugene\n"},{"id":"139343","messageId":"4BC3389C.4090807@viscovery.net","threadId":"23398","inReplyTo":"q2z76c5b8581004120709t860ff112i5dd057327b94ad0e@mail.gmail.com","subject":"Re: [BUG] - git rebase -i performs rebase when it shouldn't?","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-04-12T15:13:32Z","receivedAt":"2010-04-12T15:13:32Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 4/12/2010 16:09, schrieb Eugene Sajine:\n> esajine@ESAJINEWWW /c/git_repos/test2 (topic)\n> $ git rebase master\n> Current branch topic is up to date.\n> <======= Really? Topic is actually based on next – what does this \"up\n> to date\" mean??\n\nWhy should rebase bother? The difference between master and topic are\n*two* commits. Since these two are already on top of master in linear\nhistory, you get no advantage by doing a rebase operation. Therefore, you\nsee \"already up to date\".\n\nThe fact that the second commit from the tip of topic is also labeled\n\"next\" is absolutely irrelevant to rebase. rebase only looks at the refs\nthat you tell it about: master and topic (implicitly pointed to by HEAD),\nnothing else.\n\nWhat you really want to do, obviously, is:\n\n git rebase --onto master next topic\n\nNo, there is no shorter form to spell this operation.\n\n> esajine@ESAJINEWWW /c/git_repos/test2 (topic)\n> $ git rebase -i --onto master topic\n> Successfully rebased and updated refs/heads/topic. <=== BUG – here it\n> printed me “noop” in file to edit, when I exited it should do nothing,\n> but it still did something and I double checked it.\n\nNot a bug.\n\nYour command is the same as\n\n git rebase -i --onto master topic topic\n\nbecause you are already on branch topic. Since there are no commits in the\nrange topic..topic, rebase -i told you \"noop\". This word is perhaps poorly\nchosen, because it does not mean \"no operation\"[*], but \"there are no\ncommits to transfer\". But branch 'topic' that you gave as the last\nargument (or implicitly by being at branch 'topic') is still transferred\n--onto master. This explains the result that you observed.\n\nOf course, if you do not 'reset --hard topic@{1}' at this point, you will\nultimately lose the commits on branch topic.\n\n[*] You can get \"no operation\" by deleting the line \"noop\".\n\n-- Hannes\n"},{"id":"139344","messageId":"w2t76c5b8581004120828p8e1e5c49m7bcc53c8c3e68d06@mail.gmail.com","threadId":"23398","inReplyTo":"4BC3389C.4090807@viscovery.net","subject":"Re: [BUG] - git rebase -i performs rebase when it shouldn't?","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-04-12T15:28:37Z","receivedAt":"2010-04-12T15:28:37Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"On Mon, Apr 12, 2010 at 11:13 AM, Johannes Sixt wrote:\n> Am 4/12/2010 16:09, schrieb Eugene Sajine:\n>> esajine@ESAJINEWWW /c/git_repos/test2 (topic)\n>> $ git rebase master\n>> Current branch topic is up to date.\n>> <======= Really? Topic is actually based on next – what does this \"up\n>> to date\" mean??\n>\n> Why should rebase bother? The difference between master and topic are\n> *two* commits. Since these two are already on top of master in linear\n> history, you get no advantage by doing a rebase operation. Therefore, you\n> see \"already up to date\".\n\nYou lost me completely...\nRebase means change the base of the commit, change the fork point.\nCurrent fork point for topic is next. I want it to be master. What is\nup to date here???\nThe message is poorly worded for sure.\n\nI know that the form i have to use is:\n\ngit rebase --onto master next topic\n\nbut it is just because topic is not direct descendant of master, isn't it?\n\n\n>\n>> esajine@ESAJINEWWW /c/git_repos/test2 (topic)\n>> $ git rebase -i --onto master topic\n>> Successfully rebased and updated refs/heads/topic. <=== BUG – here it\n>> printed me “noop” in file to edit, when I exited it should do nothing,\n>> but it still did something and I double checked it.\n>\n> Not a bug.\n>\n> Your command is the same as\n>\n>   git rebase -i --onto master topic topic\n>\n> because you are already on branch topic. Since there are no commits in the\n> range topic..topic, rebase -i told you \"noop\". This word is perhaps poorly\n> chosen, because it does not mean \"no operation\"[*], but \"there are no\n> commits to transfer\". But branch 'topic' that you gave as the last\n> argument (or implicitly by being at branch 'topic') is still transferred\n> --onto master. This explains the result that you observed.\n>\n> Of course, if you do not 'reset --hard topic@{1}' at this point, you will\n> ultimately lose the commits on branch topic.\n>\n> [*] You can get \"no operation\" by deleting the line \"noop\".\n>\n> -- Hannes\n>\n\nCome on! Please, please, explain me why it behaves DIFFERENTLY:\n\nesajine@ESAJINEWWW /c/git_repos/test2 (topic)\n$ git rebase --onto master topic\nFirst, rewinding head to replay your work on top of it...\nfatal: Not a range.\nNothing to do.\n <======== topic..HEAD is not a range, agreed\n\n\nesajine@ESAJINEWWW /c/git_repos/test2 (topic)\n$ git rebase -i --onto master topic\nSuccessfully rebased and updated refs/heads/topic. <=== BUG – here it\nprinted me “noop” in file to edit, when I exited it should do nothing,\nbut it still did something and I double checked it.\n\n\nThanks,\nEugene\n"},{"id":"139346","messageId":"4BC3407C.10701@viscovery.net","threadId":"23398","inReplyTo":"w2t76c5b8581004120828p8e1e5c49m7bcc53c8c3e68d06@mail.gmail.com","subject":"Re: [BUG] - git rebase -i performs rebase when it shouldn't?","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-04-12T15:47:08Z","receivedAt":"2010-04-12T15:47:08Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 4/12/2010 17:28, schrieb Eugene Sajine:\n> On Mon, Apr 12, 2010 at 11:13 AM, Johannes Sixt wrote:\n>> Am 4/12/2010 16:09, schrieb Eugene Sajine:\n>>> esajine@ESAJINEWWW /c/git_repos/test2 (topic)\n>>> $ git rebase master\n>>> Current branch topic is up to date.\n>>> <======= Really? Topic is actually based on next – what does this \"up\n>>> to date\" mean??\n>>\n>> Why should rebase bother? The difference between master and topic are\n>> *two* commits. Since these two are already on top of master in linear\n>> history, you get no advantage by doing a rebase operation. Therefore, you\n>> see \"already up to date\".\n> \n> You lost me completely...\n> Rebase means change the base of the commit, change the fork point.\n\nRebase is meant to change the fork point for a history like this:\n\n --o--o--A--o--o--B <-- master\n \\\n o\n \\\n o <-- topic\n\ntopic forks from master at commit A; you use rebase to create history that\nlooks like this:\n\n --o--o--A--o--o--B <-- master\n \\\n o\n \\\n o <-- topic\n\n(OK, you knew that already.)\n\n> Current fork point for topic is next. I want it to be master. What is\n> up to date here???\n\nYou are already in the second situation above. The fact that you labeled\none commit \"next\" in between, like this:\n\n --o--o--A--o--o--B <-- master\n \\\n o <-- next\n \\\n o <-- topic\n\ndoes not change the meaning of the command \"git rebase master\" in the\nslightest: topic is \"up to date\" with respect to master.\n\n> The message is poorly worded for sure.\n> \n> I know that the form i have to use is:\n> \n> git rebase --onto master next topic\n> \n> but it is just because topic is not direct descendant of master, isn't it?\n\nWatch out the wording that you use: \"descendant of\" has a well-defined\nmeaning in git, in particular, topic *is* a direct descendant of master.\n\nWhat you wanted to say is: \"but it is just because I have accidentally\nbegun to commit 'topic' on top of 'next', but I didn't want to do that\".\n\nAnd yes, you are right, because of this you need --onto in the rebase command.\n\n> Come on! Please, please, explain me why it behaves DIFFERENTLY:\n> \n> esajine@ESAJINEWWW /c/git_repos/test2 (topic)\n> $ git rebase --onto master topic\n> First, rewinding head to replay your work on top of it...\n> fatal: Not a range.\n> Nothing to do.\n> <======== topic..HEAD is not a range, agreed\n> \n> \n> esajine@ESAJINEWWW /c/git_repos/test2 (topic)\n> $ git rebase -i --onto master topic\n> Successfully rebased and updated refs/heads/topic. <=== BUG – here it\n> printed me “noop” in file to edit, when I exited it should do nothing,\n> but it still did something and I double checked it.\n\nA historical accident, so to say. The implementor of interactive rebase\nfelt the \"noop\" behavior was useful, and I agree, FWIW.\n\n-- Hannes\n"},{"id":"139361","messageId":"201004121939.17562.j6t@kdbg.org","threadId":"23398","inReplyTo":"20100412105034.GC30605@mageo.cz","subject":"Re: [BUG] - git rebase -i performs rebase when it shouldn't?","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2010-04-12T17:39:17Z","receivedAt":"2010-04-12T17:39:17Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Montag, 12. April 2010, Michal Vitecek wrote:\n> Is there any chance for merge to behave the same? I really like that I\n> don't have to do a checkout prior rebasing.\n\nIf you mean \"prior to merging\", i.e., you want a \"git merge --into master\", \nyou can do it this way:\n\n# we are on branch 'topic' here\ngit checkout HEAD^0\t# detach\ngit merge master\ngit reset --soft master\t# keep index(!!!) and worktree\ngit checkout master\t# re-attach\ngit merge topic\n\nThe point is that the second merge will succeed even with a dirty index \nbecause for each file the result of the merge is identical to the index!\n\nIf you have conflicts during the merge, resolve them in the first merge and \ncommit to prime the rerere database; the second merge will fail for each \nconflicting file; just 'git checkout HEAD -- the/conflicting/file' and retry. \nrerere will resolve the conflicts for you.\n\nYou can of course get away with only one merge, but then you will have to do \nextra work to switch the parents around and to fix the commit message.\n\n-- Hannes\n"},{"id":"139424","messageId":"p2l76c5b8581004130930rf5558655n4bb1f6d0c659498d@mail.gmail.com","threadId":"23398","inReplyTo":"4BC3407C.10701@viscovery.net","subject":"Re: [BUG] - git rebase -i performs rebase when it shouldn't?","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-04-13T16:30:08Z","receivedAt":"2010-04-13T16:30:08Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":">\n>> Come on! Please, please, explain me why it behaves DIFFERENTLY:\n>>\n>> esajine@ESAJINEWWW /c/git_repos/test2 (topic)\n>> $ git rebase --onto master topic\n>> First, rewinding head to replay your work on top of it...\n>> fatal: Not a range.\n>> Nothing to do.\n>>                 <======== topic..HEAD is not a range, agreed\n>>\n>>\n>> esajine@ESAJINEWWW /c/git_repos/test2 (topic)\n>> $ git rebase -i --onto master topic\n>> Successfully rebased and updated refs/heads/topic. <=== BUG – here it\n>> printed me “noop” in file to edit, when I exited it should do nothing,\n>> but it still did something and I double checked it.\n>\n> A historical accident, so to say. The implementor of interactive rebase\n> felt the \"noop\" behavior was useful, and I agree, FWIW.\n>\n> -- Hannes\n>\n\nIMHO this \"noop\" behavior seems to be identical to \"git reset --hard\nmaster\" - the result is the same. Frankly, I don't understand what is\nuseful in such thing being HIDDEN in \"incorrect call\" of interactive\nrebase...\n\nThanks,\nEugene\n"},{"id":"139455","messageId":"4BC55BD3.3050204@viscovery.net","threadId":"23398","inReplyTo":"p2l76c5b8581004130930rf5558655n4bb1f6d0c659498d@mail.gmail.com","subject":"Re: [BUG] - git rebase -i performs rebase when it shouldn't?","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-04-14T06:08:19Z","receivedAt":"2010-04-14T06:08:19Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 4/13/2010 18:30, schrieb Eugene Sajine:\n> IMHO this \"noop\" behavior seems to be identical to \"git reset --hard\n> master\" - the result is the same. Frankly, I don't understand what is\n> useful in such thing being HIDDEN in \"incorrect call\" of interactive\n> rebase...\n\nThis thing is useful when you 'git rebase -i master topic' and all patches\non topic are already in master.\n\n-- Hannes\n"}]}