{"thread":{"id":"23396","subject":"git rebase command and docs questions","startedAt":"2010-04-09T18:49:52Z","lastAt":"2010-04-10T22:40:45Z","messageCount":8,"participants":["Eugene Sajine","Sverre Rabbelier","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"139060","messageId":"h2j76c5b8581004091149y9f5f93a8o5f11b3ffc657623@mail.gmail.com","threadId":"23396","inReplyTo":null,"subject":"git rebase command and docs questions","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-04-09T18:49:52Z","receivedAt":"2010-04-09T18:49:52Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"Hi,\n\nI have few questions about rebase and its help content:\n\n1. In case of this situation\n\no---o---o---o---o  master\n        \\\n         o---o---o---o---o  next\n                          \\\n                           o---o---o  topic\n\n\n“git rebase master topic” says:\nThe current branch topic is up-to-date.\n\nThis message seems to be confusing and even incorrect.\nThe actual problem, as I understand, is that topic branch is not a\ndirect descendant of the master branch, therefore\n“git rebase –onto master next topic” should be used instead.\nIs there a way for git to identify this problem more correctly and\nprint more helpful error message?\n\n2. The rebase help is a bit confusing in its “–onto” option part.\nInitially help says that the form:\n\ngit rebase master topic\n\nis a shorthand for git checkout topic, git rebase master\n\nBut, in “git rebase –onto master next topic” the meaning of the “next\ntopic” parameters is different: as I understand, it actually specifies\na range of commits from next to topic,  because –onto changes the way\nthe whole command is working, but it is not clarified in help. Is that\ncorrect understanding?\n\n\n3. The part of help from “Another example of --onto option is to\nrebase part of a branch.” Is actually demonstrating absolutely the\nsame thing as the one before with the only difference that in the\nsecond example the master has not advanced. There was probably some\ndifferent intention, but currently it looks like confusing\nduplication.\n\nThanks,\nEugene\n"},{"id":"139073","messageId":"r2mfabb9a1e1004091337w8ec2b721y3a5082d5e0f5925c@mail.gmail.com","threadId":"23396","inReplyTo":"h2j76c5b8581004091149y9f5f93a8o5f11b3ffc657623@mail.gmail.com","subject":"Re: git rebase command and docs questions","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-04-09T20:37:15Z","receivedAt":"2010-04-09T20:37:15Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Fri, Apr 9, 2010 at 20:49, Eugene Sajine wrote:\n> But, in “git rebase –onto master next topic” the meaning of the “next\n> topic” parameters is different: as I understand, it actually specifies\n> a range of commits from next to topic,  because –onto changes the way\n> the whole command is working, but it is not clarified in help. Is that\n> correct understanding?\n\nI've never been able to remember how rebase --onto works, perhaps if\nwe actually let users specify a range it would be more intuitive?\n\n$ git rebase next..topic master\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"139074","messageId":"p2m76c5b8581004091351o8ed7877ch1361f0089d3bdf79@mail.gmail.com","threadId":"23396","inReplyTo":"r2mfabb9a1e1004091337w8ec2b721y3a5082d5e0f5925c@mail.gmail.com","subject":"Re: git rebase command and docs questions","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-04-09T20:51:06Z","receivedAt":"2010-04-09T20:51:06Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"On Fri, Apr 9, 2010 at 4:37 PM, Sverre Rabbelier wrote:\n> Heya,\n>\n> On Fri, Apr 9, 2010 at 20:49, Eugene Sajine wrote:\n>> But, in “git rebase –onto master next topic” the meaning of the “next\n>> topic” parameters is different: as I understand, it actually specifies\n>> a range of commits from next to topic,  because –onto changes the way\n>> the whole command is working, but it is not clarified in help. Is that\n>> correct understanding?\n>\n> I've never been able to remember how rebase --onto works, perhaps if\n> we actually let users specify a range it would be more intuitive?\n>\n> $ git rebase next..topic master\n\nI thought about it too. Even with the old syntax:\n\ngit rebase --onto master next..topic\n\nat least as a second option the whole command would be much more\nunderstandable for users. Currently, it fails with such range.\n\nThanks,\nEugene\n"},{"id":"139076","messageId":"7vhbnk1gc6.fsf@alter.siamese.dyndns.org","threadId":"23396","inReplyTo":"r2mfabb9a1e1004091337w8ec2b721y3a5082d5e0f5925c@mail.gmail.com","subject":"Re: git rebase command and docs questions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-09T21:11:37Z","receivedAt":"2010-04-09T21:11:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier writes:\n\n> On Fri, Apr 9, 2010 at 20:49, Eugene Sajine wrote:\n>> But, in “git rebase –onto master next topic” the meaning of the “next\n>> topic” parameters is different: as I understand, it actually specifies\n>> a range of commits from next to topic, because –onto changes the way\n>> the whole command is working, but it is not clarified in help. Is that\n>> correct understanding?\n>\n> I've never been able to remember how rebase --onto works, perhaps if\n> we actually let users specify a range it would be more intuitive?\n>\n> $ git rebase next..topic master\n\nHmm, re*base* means \"change the base to _this one_\"; the above is more\nlike \"replay these on master\", which is often a useful operation but is\ndifferent.\n\nSuppose other people have worked on the project and made their pushes\nsince you started working on your changes:\n\n o---o master\n /\n ---o---o---o---o origin\n\n\"git rebase origin\" asks \"I know my current work is based on a tad stale\nstate, and I'd prefer a linear history, so change the base to origin\".\n\nIf the thing of whose base you want to change is not your \"current work\",\nthen you name that explicitly, i.e. \"git rebase origin master\" (i.e. the\nsecond branch name defaults to HEAD as usual).\n\nOnto is an optional feature that is primarily for correcting your earlier\nmistakes. Notice in the above picture, other people doing parallel work\nand pushing their changes out is part of the normal life of distributed\ndevelopment; there is no mistake on your part involved.\n\nBut suppose you started building bugfixes in a topic forked from origin,\nbut after that you realize they should be based on origin/maint:\n\n X---Y fixes\n /\n o---o---o---o---o origin\n /\n ---o---o---o origin/maint\n\nYou could have made fixes branch that houses X and Y on origin/maint (and\nlater merge that to master to be pushed to origin), but you did not have\nperfect foresight. You do not obviously want to change the base of whole\n'fixes' branch to 'origin/maint', as that will pull in changes in origin\nthat are not related to your fixes.\n\nYou would want to rebase 'fixes' branch (whose fork point can be specified\nwith 'origin') but not on top of 'origin', but on 'origin/maint'. Hence\ninstead of running \"git rebase origin\" to produce\n\n X'--Y' fixes\n /\n o---o---o---o---o origin\n /\n ---o---o---o origin/maint\n\nYou would say \"git rebase --onto origin/maint origin\" to transplant X' and\nY' as if you started working from 'origin/maint':\n\n\n o---o---o---o---o origin\n /\n ---o---o---o origin/maint\n \\\n X'--Y' fixes\n\nIf you _had_ your \"replay\" command, the workflow for this would be:\n\n $ git checkout -b maint-fixes origin/maint\n $ git replay origin..fixes\n\n\nBefore somebody else makes useless noises, \"cherry-pick\" could be a good\ncommand in the existing UI set to do that kind of thing.\n"},{"id":"139077","messageId":"l2nfabb9a1e1004091423te78b692btd8bbb03785f94a16@mail.gmail.com","threadId":"23396","inReplyTo":"7vhbnk1gc6.fsf@alter.siamese.dyndns.org","subject":"Re: git rebase command and docs questions","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-04-09T21:23:23Z","receivedAt":"2010-04-09T21:23:23Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Fri, Apr 9, 2010 at 23:11, Junio C Hamano wrote:\n> Hmm, re*base* means \"change the base to _this one_\"; the above is more\n> like \"replay these on master\", which is often a useful operation but is\n> different.\n\nYes, I guess that's true.\n\n> If you _had_ your \"replay\" command, the workflow for this would be:\n>\n>    $ git checkout -b maint-fixes origin/maint\n>    $ git replay origin..fixes\n\nTrue again.\n\n> Before somebody else makes useless noises, \"cherry-pick\" could be a good\n> command in the existing UI set to do that kind of thing.\n\nI still think the UI for --onto is awkward. At the very least it should be:\n\ngit rebase --fork-at=origin origin/maint fixes\n\nOr something like that. Since currently you suddenly have to specify\nan argument to --onto that was previously positional. Does that make\nsense?\n\nCase 1:\ngit rebase origin fixes\ngit rebase \n\nCase 2:\ngit rebase --onto origin/maint origin fixes\ngit rebase --onto= \n\nI know that in the --onto case is not an argument to\n--onto, but that's what it looks/feels like. Said differently, it's\njust _really weird_ that a new argument (for a different mode) shows\nup between two other arguments. It should either be at the beginning,\nor at the end, but in the middle is just awkward, no?\n\nSo another solution might be to change the position of the\n in the --onto case.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"139208","messageId":"s2l76c5b8581004101530h171f3c2dv6a2fc9d4225fbd4e@mail.gmail.com","threadId":"23396","inReplyTo":"l2nfabb9a1e1004091423te78b692btd8bbb03785f94a16@mail.gmail.com","subject":"Re: git rebase command and docs questions","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-04-10T22:30:56Z","receivedAt":"2010-04-10T22:30:56Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"On Fri, Apr 9, 2010 at 5:23 PM, Sverre Rabbelier wrote:\n> Heya,\n>\n> On Fri, Apr 9, 2010 at 23:11, Junio C Hamano wrote:\n>> Hmm, re*base* means \"change the base to _this one_\"; the above is more\n>> like \"replay these on master\", which is often a useful operation but is\n>> different.\n>\n> Yes, I guess that's true.\n\nI'm a bit confused. Isn't the rebase actually replaying the commits\none by one starting from new base instead of old one?\nI believe it does apply diffs one by one, else there would be no\nconflicts during rebase whatsoever.\nSecondly, git complains about range not specified if you will try to\nexecute something like\n\ngit rebase --onto master topic\n\nwhen topic is not direct descendant of master.\nGit will say \"not a range\".\n\nSo, That's why i make a conclusion that the real meaning of\n\ngit rebase --onto master next topic\n\nis very close if not exactly matching the\n\ngit rebase --onto master next..topic\n\n>\n>> If you _had_ your \"replay\" command, the workflow for this would be:\n>>\n>>    $ git checkout -b maint-fixes origin/maint\n>>    $ git replay origin..fixes\n>\n> True again.\n>Yep therefore the interface\n>\n>> Before somebody else makes useless noises, \"cherry-pick\" could be a good\n>> command in the existing UI set to do that kind of thing.\n>\n> I still think the UI for --onto is awkward. At the very least it should be:\n>\n> git rebase --fork-at=origin origin/maint fixes\n>\n> Or something like that. Since currently you suddenly have to specify\n> an argument to --onto that was previously positional. Does that make\n> sense?\n>\n> Case 1:\n> git rebase origin fixes\n> git rebase \n>\n> Case 2:\n> git rebase --onto origin/maint origin fixes\n> git rebase --onto= \n>\n> I know that in the --onto case is not an argument to\n> --onto, but that's what it looks/feels like.\n\nHow is that possible that it is not an argument to --onto???\n\nfrom docs:\n\nSYNOPSIS\n\ngit rebase [-i | --interactive] [options] [--onto ]\n []\ngit rebase [-i | --interactive] [options] --onto \n --root []\ngit rebase --continue | --skip | --abort\n\nWhen i'm executing\ngit rebase --onto master next topic\n\nmaster is exactly the new base, new fork point for topic, which was\npreviously forked from next!\n\n>Said differently, it's\n> just _really weird_ that a new argument (for a different mode) shows\n> up between two other arguments. It should either be at the beginning,\n> or at the end, but in the middle is just awkward, no?\n>\n> So another solution might be to change the position of the\n> in the --onto case.\n>\n> --\n> Cheers,\n>\n> Sverre Rabbelier\n>\n"},{"id":"139212","messageId":"j2kfabb9a1e1004101532tf16f9d55y404b5f7595d587c3@mail.gmail.com","threadId":"23396","inReplyTo":"s2l76c5b8581004101530h171f3c2dv6a2fc9d4225fbd4e@mail.gmail.com","subject":"Re: git rebase command and docs questions","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-04-10T22:32:26Z","receivedAt":"2010-04-10T22:32:26Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Sun, Apr 11, 2010 at 00:30, Eugene Sajine wrote:\n> How is that possible that it is not an argument to --onto???\n\nWhat I meant is that it's not \"--onto=\", \"--onto\" is a boolean flag.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"139214","messageId":"p2s76c5b8581004101540h729564e8vc87fa269143b3633@mail.gmail.com","threadId":"23396","inReplyTo":"j2kfabb9a1e1004101532tf16f9d55y404b5f7595d587c3@mail.gmail.com","subject":"Re: git rebase command and docs questions","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-04-10T22:40:45Z","receivedAt":"2010-04-10T22:40:45Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"On Sat, Apr 10, 2010 at 6:32 PM, Sverre Rabbelier wrote:\n> Heya,\n>\n> On Sun, Apr 11, 2010 at 00:30, Eugene Sajine wrote:\n>> How is that possible that it is not an argument to --onto???\n>\n> What I meant is that it's not \"--onto=\", \"--onto\" is a boolean flag.\n>\n> --\n> Cheers,\n>\n> Sverre Rabbelier\n>\n\nOh, OK. I didn't know that - your paragraph makes sense to me now;)\nThanks!\n\nStill all three questions from original mail are open...\n\nThanks,\nEugene\n"}]}