{"thread":{"id":"13097","subject":"Re: [PATCH/RFC 01/10] Teach rebase interactive the mark command","startedAt":"2008-04-13T20:51:50Z","lastAt":"2008-04-15T00:11:15Z","messageCount":4,"participants":["Paul Fredrickson","Jörg Sommer","Johannes Schindelin","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":10},"messages":[{"id":"74272","messageId":"69a88a530804131351n7d9f8188vf2bbb0174ade3ca0@mail.gmail.com","threadId":"13097","inReplyTo":null,"subject":"Re: [PATCH/RFC 01/10] Teach rebase interactive the mark command","fromName":"Paul Fredrickson","fromEmail":"paul.fredrickson@gmail.com","sentAt":"2008-04-13T20:51:50Z","receivedAt":"2008-04-13T20:51:50Z","isPatch":true,"sender":{"key":"paul.fredrickson@gmail.com","avatar":"https://gravatar.com/avatar/77589a1addc2a9a2a4a67b1ea546e8362df646a32e7ffca015aad570030a6684?d=mp&s=160"},"body":"> Jrg Sommer wrote:\n> > > Wouldn't\n> > >\n> > > pick 5cc8f37 (init: show \"Reinit\" message even in ...)\n> > > mark 1\n> > > pick 18d077c (quiltimport: fix misquoting of parse...)\n> > > mark 2\n> > > reset 1\n> >\n> > \"reset 18d077c~2\" or \"reset some-tag\" or \"reset my-branch~12\"\n> >\n> > merge #2\n> > >\n> > > be easier for people?\n> >\n> > I don't know. Using the special sign everywhere a mark is used looks more\n> > consistent to me. The only case where it might be omitted is the mark\n> > command, because it only uses marks.\n>\n> Why not use the mark syntax that fast-import uses? In fast-import\n> we use \":n\" anytime we need to refer to a mark, e.g. \":1\" or \":5\".\n> Its the same idea. We already have a language for it. Heck, the\n> commands above are bordering on a language not too far from the\n> one that fast-import accepts. :-)\n\nI like the idea of adding marks to an interactive rebase in general, but instead\nof adding a separate command, what if rebase *automatically* marked all the\ncommits in the session:\n\n 1: pick 5cc8f37 (init: show \"Reinit\" message even in ...)\n 2: pick 18d007c (quiltimport: fix misquoting of parse ...)\n reset 1\n merge 2\n\nor \"reset :1\" and \"merge :2\". Neither notation bothers me for marks.\n\n--Paul\n"},{"id":"74346","messageId":"20080414092749.GA15098@alea.gnuu.de","threadId":"13097","inReplyTo":"69a88a530804131351n7d9f8188vf2bbb0174ade3ca0@mail.gmail.com","subject":"Re: [PATCH/RFC 01/10] Teach rebase interactive the mark command","fromName":"Jörg Sommer","fromEmail":"joerg@alea.gnuu.de","sentAt":"2008-04-14T09:27:49Z","receivedAt":"2008-04-14T09:27:49Z","isPatch":true,"sender":{"key":"joerg@alea.gnuu.de","avatar":null},"body":"Hello Paul,\n\nPaul Fredrickson schrieb am Sun 13. Apr, 13:51 (-0700):\n> > Jrg Sommer wrote:\n> > > > Wouldn't\n> > > >\n> > > > pick 5cc8f37 (init: show \"Reinit\" message even in ...)\n> > > > mark 1\n> > > > pick 18d077c (quiltimport: fix misquoting of parse...)\n> > > > mark 2\n> > > > reset 1\n> \n> I like the idea of adding marks to an interactive rebase in general, but instead\n> of adding a separate command, what if rebase *automatically* marked all the\n> commits in the session:\n> \n> 1: pick 5cc8f37 (init: show \"Reinit\" message even in ...)\n> 2: pick 18d007c (quiltimport: fix misquoting of parse ...)\n> reset 1\n> merge 2\n\nThis format would be incompatible with the current format and it makes\nthe parsing a little bit more difficult; the first column contains a mark\nor a command. No, I think that's not a good idea.\n\nHave a nice day, Jörg.\n-- \nDer Hase läuft schneller als der Fuchs,\ndenn der Hase läuft um sein Leben.\n"},{"id":"74352","messageId":"alpine.DEB.1.00.0804141506270.28504@racer","threadId":"13097","inReplyTo":"69a88a530804131351n7d9f8188vf2bbb0174ade3ca0@mail.gmail.com","subject":"Re: [PATCH/RFC 01/10] Teach rebase interactive the mark command","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-14T14:10:18Z","receivedAt":"2008-04-14T14:10:18Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 13 Apr 2008, Paul Fredrickson wrote:\n\n> > Jrg Sommer wrote:\n> > > > Wouldn't\n> > > >\n> > > > pick 5cc8f37 (init: show \"Reinit\" message even in ...)\n> > > > mark 1\n> > > > pick 18d077c (quiltimport: fix misquoting of parse...)\n> > > > mark 2\n> > > > reset 1\n> > >\n> > > \"reset 18d077c~2\" or \"reset some-tag\" or \"reset my-branch~12\"\n> > >\n> > > merge #2\n> > > >\n> > > > be easier for people?\n\nActually, I think that this whole \"mark\" stuff is way too complicated, as \ncan be seen by the amount of patches needed to get it somewhere usable.\n\nI would like it much better, if there was something like\n\npick 5cc8f37 (init: show \"Reinit\" message even in ...)\npick 18d077c (quiltimport: fix misquoting of parse...)\nmerge 9876543:5cc8f37,18d077c (Merge blub)\nreset 5cc8f37\n...\n\nI.e. like with filter-branch, and like with rebase -i -p in its current \nform, we take the _original_ names as keys as to which commits to merge, \nor where to reset to.\n\nThat would be relatively easy to implement, since the whole infrastructure \nfor it is already there: whenever a commit was rewritten, the new commit \nname is saved in $DOTEST/rewritten/.\n\nI really do not like complicating things unnecessarily.\n\nCiao,\nDscho\n"},{"id":"74392","messageId":"7vve2k6kpo.fsf@gitster.siamese.dyndns.org","threadId":"13097","inReplyTo":"alpine.DEB.1.00.0804141506270.28504@racer","subject":"Re: [PATCH/RFC 01/10] Teach rebase interactive the mark command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-15T00:11:15Z","receivedAt":"2008-04-15T00:11:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> I would like it much better, if there was something like\n>\n> pick 5cc8f37 (init: show \"Reinit\" message even in ...)\n> pick 18d077c (quiltimport: fix misquoting of parse...)\n> merge 9876543:5cc8f37,18d077c (Merge blub)\n> reset 5cc8f37\n> ...\n>\n> I.e. like with filter-branch, and like with rebase -i -p in its current \n> form, we take the _original_ names as keys as to which commits to merge, \n> or where to reset to.\n\nWhile the need probably would not be felt strongly if we design this only\nfor rebase -i, I suspect that you would want to have two kinds of reset if\nyou go that route. There might be some other insn that may have similar\nissues.\n\nFor example, imagine a case where you want to create a merge with a\nrecontructed side branch. First you grow the branch you would merge into,\nwith a sequence:\n\n\tpick A\n pick B\n pick C\n\nThen in order to reconstruct a side branch that begins from a known point,\nsay the tip of \"master\", you would want to reset to a commit that is\noutside of the scope of this rewriting. And then you rebuild that side\nbranch:\n\n\treset master\n pick D\n pick E\n\nAnd finally (and this step shows the beauty of your approach), come back\nto the other tip and make the merge:\n\n\treset C\n merge E\n\nTwo resets above would have different semantics. The former resets to\nunwritten, and the latter rewritten.\n"}]}