{"thread":{"id":"16207","subject":"[minor usability suggestion] git rebase --onto ?","startedAt":"2008-11-07T09:20:35Z","lastAt":"2008-11-08T11:49:56Z","messageCount":5,"participants":["Ingo Molnar","Junio C Hamano","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"95110","messageId":"20081107092035.GA1339@elte.hu","threadId":"16207","inReplyTo":null,"subject":"[minor usability suggestion] git rebase --onto ?","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2008-11-07T09:20:35Z","receivedAt":"2008-11-07T09:20:35Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\nI use git rebase rarely, but i just had one of those exceptions where \nit's OK to use it: wanted to zap an unsafe commit [685aebb below] from \na short-lifetime topic branch. With that i had this small usability \nincident:\n\n earth4:~/tip> tc\n tip/core/urgent 82d4e6e: xen: make sure stray alias mappings are gone\n\n earth4:~/tip> git rebase 685aebb --onto linus\n Current branch core/urgent is up to date.\n\n earth4:~/tip> glll\n 82d4e6e: xen: make sure stray alias mappings are gone before pinning\n f6ab176: vmap: cope with vm_unmap_aliases before vmalloc_init()\n 685aebb: kernel/cpu.c: section mismatch warning fix\n\n earth4:~/tip> git rebase --onto linus 685aebb\n First, rewinding head to replay your work on top of it...\n Applying: vmap: cope with vm_unmap_aliases before vmalloc_init()\n Applying: xen: make sure stray alias mappings are gone before pinning\n\n earth4:~/tip> glll\n d05fdf3: xen: make sure stray alias mappings are gone before pinning\n 9b46333: vmap: cope with vm_unmap_aliases before vmalloc_init()\n\n earth4:~/tip> tc\n tip/core/urgent d05fdf3: xen: make sure stray alias mappings are gone \n\n earth4:~/tip> git version\n git version 1.6.0.2.GIT\n\nWhat i tried to achieve was to zap a single commit that was applied \nfirst, and preserve the other two commits - without having to go via \nthe longer \"git rebase -i\" path.\n\nIt took me some time to figure out that while the principle i applied \nwas correct, the first rebase command didnt work because i mistakenly \nflipped around the \"--onto \" arguments to \n\" --onto \".\n\nUnless the reverse order is meaningful and important, it might make \nsense to flip it back implicitly and thus accept that order as well \ntransparently.\n\nFor example \"git log\" is exemplary in this area as it accepts just \nabout any permutation of parameters thrown at it, and i love that \naspect of Git commands in general, it's a really nice property.\n\nOr at least we should print some sort of warning/error? The \"Current \nbranch core/urgent is up to date.\" message definitely did not help me \nin noticing my mistake.\n\n\tIngo\n"},{"id":"95134","messageId":"7vej1ngztd.fsf@gitster.siamese.dyndns.org","threadId":"16207","inReplyTo":"20081107092035.GA1339@elte.hu","subject":"Re: [minor usability suggestion] git rebase --onto ?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-07T18:23:42Z","receivedAt":"2008-11-07T18:23:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ingo Molnar writes:\n\n> earth4:~/tip> git rebase 685aebb --onto linus\n> Current branch core/urgent is up to date.\n> ...\n> For example \"git log\" is exemplary in this area as it accepts just \n> about any permutation of parameters thrown at it, ...\n\nNot really.\n\nThere may be oddball commands whose parameter order have been established\ndifferently long before \"git log\" came, but almost all of them now use the\nsame convention used by the \"git log\" family, which is flags/options then\nrevs (and then paths if the operation makes sense with paths). And rebase\nis not one of the oddball ones.\n\nYour \"rebase\" example is a rev then a flag/option, which is not how any\nother git command take its command line parameters.\n\n> Or at least we should print some sort of warning/error?\n\nWith that I agree with. Patches? ;-)\n"},{"id":"95140","messageId":"alpine.LNX.1.00.0811071504110.19665@iabervon.org","threadId":"16207","inReplyTo":"7vej1ngztd.fsf@gitster.siamese.dyndns.org","subject":"Re: [minor usability suggestion] git rebase --onto ?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-11-07T20:10:32Z","receivedAt":"2008-11-07T20:10:32Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 7 Nov 2008, Junio C Hamano wrote:\n\n> Ingo Molnar writes:\n> \n> > earth4:~/tip> git rebase 685aebb --onto linus\n> > Current branch core/urgent is up to date.\n> > ...\n> > For example \"git log\" is exemplary in this area as it accepts just \n> > about any permutation of parameters thrown at it, ...\n> \n> Not really.\n> \n> There may be oddball commands whose parameter order have been established\n> differently long before \"git log\" came, but almost all of them now use the\n> same convention used by the \"git log\" family, which is flags/options then\n> revs (and then paths if the operation makes sense with paths). And rebase\n> is not one of the oddball ones.\n> \n> Your \"rebase\" example is a rev then a flag/option, which is not how any\n> other git command take its command line parameters.\n\n\"git log origin/master -p\" works, though. It's paths, not revisions, that \ncan't appear before options (or revisions).\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"95145","messageId":"7vy6zvfdp5.fsf@gitster.siamese.dyndns.org","threadId":"16207","inReplyTo":"alpine.LNX.1.00.0811071504110.19665@iabervon.org","subject":"Re: [minor usability suggestion] git rebase --onto ?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-07T21:06:46Z","receivedAt":"2008-11-07T21:06:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> \"git log origin/master -p\" works, though.\n\nThat's an accident. Do not rely on it.\n"},{"id":"95210","messageId":"20081108114955.GC8354@elte.hu","threadId":"16207","inReplyTo":"7vy6zvfdp5.fsf@gitster.siamese.dyndns.org","subject":"Re: [minor usability suggestion] git rebase --onto ?","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2008-11-08T11:49:56Z","receivedAt":"2008-11-08T11:49:56Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> > \"git log origin/master -p\" works, though.\n> \n> That's an accident. Do not rely on it.\n\nhm, i frequently rely on tacking-on options after the fact, especially \nthe -- ones.\n\nJust like the best workflow is append-mostly, command parameters are \noften added append-only as well, without jumping back and forth in the \ncommand line to edit the command.\n\nPath or brach names starting with '--' are weird anyway, so isnt this \na reasonable expectation? I hope i'm not misunderstanding something \nhere.\n\n\tIngo\n"}]}