# Re: [PATCH/RFC 01/10] Teach rebase interactive the mark command 4 messages from 2008-04-13 to 2008-04-15. Participants: Paul Fredrickson, Jörg Sommer, Johannes Schindelin, Junio C Hamano. Thread: https://gitlist.dev/t/13097 ## Paul Fredrickson, 2008-04-13 20:51 Subject: Re: [PATCH/RFC 01/10] Teach rebase interactive the mark command Message-ID: <69a88a530804131351n7d9f8188vf2bbb0174ade3ca0@mail.gmail.com> URL: https://gitlist.dev/e/69a88a530804131351n7d9f8188vf2bbb0174ade3ca0%40mail.gmail.com ``` > Jrg Sommer wrote: > > > Wouldn't > > > > > > pick 5cc8f37 (init: show "Reinit" message even in ...) > > > mark 1 > > > pick 18d077c (quiltimport: fix misquoting of parse...) > > > mark 2 > > > reset 1 > > > > "reset 18d077c~2" or "reset some-tag" or "reset my-branch~12" > > > > merge #2 > > > > > > be easier for people? > > > > I don't know. Using the special sign everywhere a mark is used looks more > > consistent to me. The only case where it might be omitted is the mark > > command, because it only uses marks. > > Why not use the mark syntax that fast-import uses? In fast-import > we use ":n" anytime we need to refer to a mark, e.g. ":1" or ":5". > Its the same idea. We already have a language for it. Heck, the > commands above are bordering on a language not too far from the > one that fast-import accepts. :-) I like the idea of adding marks to an interactive rebase in general, but instead of adding a separate command, what if rebase *automatically* marked all the commits in the session: 1: pick 5cc8f37 (init: show "Reinit" message even in ...) 2: pick 18d007c (quiltimport: fix misquoting of parse ...) reset 1 merge 2 or "reset :1" and "merge :2". Neither notation bothers me for marks. --Paul ``` ## Jörg Sommer, 2008-04-14 09:27 Subject: Re: [PATCH/RFC 01/10] Teach rebase interactive the mark command Message-ID: <20080414092749.GA15098@alea.gnuu.de> URL: https://gitlist.dev/e/20080414092749.GA15098%40alea.gnuu.de In-Reply-To: <69a88a530804131351n7d9f8188vf2bbb0174ade3ca0@mail.gmail.com> ``` Hello Paul, Paul Fredrickson schrieb am Sun 13. Apr, 13:51 (-0700): > > Jrg Sommer wrote: > > > > Wouldn't > > > > > > > > pick 5cc8f37 (init: show "Reinit" message even in ...) > > > > mark 1 > > > > pick 18d077c (quiltimport: fix misquoting of parse...) > > > > mark 2 > > > > reset 1 > > I like the idea of adding marks to an interactive rebase in general, but instead > of adding a separate command, what if rebase *automatically* marked all the > commits in the session: > > 1: pick 5cc8f37 (init: show "Reinit" message even in ...) > 2: pick 18d007c (quiltimport: fix misquoting of parse ...) > reset 1 > merge 2 This format would be incompatible with the current format and it makes the parsing a little bit more difficult; the first column contains a mark or a command. No, I think that's not a good idea. Have a nice day, Jörg. -- Der Hase läuft schneller als der Fuchs, denn der Hase läuft um sein Leben. ``` ## Johannes Schindelin, 2008-04-14 14:10 Subject: Re: [PATCH/RFC 01/10] Teach rebase interactive the mark command Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.0804141506270.28504%40racer In-Reply-To: <69a88a530804131351n7d9f8188vf2bbb0174ade3ca0@mail.gmail.com> ``` Hi, On Sun, 13 Apr 2008, Paul Fredrickson wrote: > > Jrg Sommer wrote: > > > > Wouldn't > > > > > > > > pick 5cc8f37 (init: show "Reinit" message even in ...) > > > > mark 1 > > > > pick 18d077c (quiltimport: fix misquoting of parse...) > > > > mark 2 > > > > reset 1 > > > > > > "reset 18d077c~2" or "reset some-tag" or "reset my-branch~12" > > > > > > merge #2 > > > > > > > > be easier for people? Actually, I think that this whole "mark" stuff is way too complicated, as can be seen by the amount of patches needed to get it somewhere usable. I would like it much better, if there was something like pick 5cc8f37 (init: show "Reinit" message even in ...) pick 18d077c (quiltimport: fix misquoting of parse...) merge 9876543:5cc8f37,18d077c (Merge blub) reset 5cc8f37 ... I.e. like with filter-branch, and like with rebase -i -p in its current form, we take the _original_ names as keys as to which commits to merge, or where to reset to. That would be relatively easy to implement, since the whole infrastructure for it is already there: whenever a commit was rewritten, the new commit name is saved in $DOTEST/rewritten/. I really do not like complicating things unnecessarily. Ciao, Dscho ``` ## Junio C Hamano, 2008-04-15 00:11 Subject: Re: [PATCH/RFC 01/10] Teach rebase interactive the mark command Message-ID: <7vve2k6kpo.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vve2k6kpo.fsf%40gitster.siamese.dyndns.org In-Reply-To: ``` Johannes Schindelin writes: > I would like it much better, if there was something like > > pick 5cc8f37 (init: show "Reinit" message even in ...) > pick 18d077c (quiltimport: fix misquoting of parse...) > merge 9876543:5cc8f37,18d077c (Merge blub) > reset 5cc8f37 > ... > > I.e. like with filter-branch, and like with rebase -i -p in its current > form, we take the _original_ names as keys as to which commits to merge, > or where to reset to. While the need probably would not be felt strongly if we design this only for rebase -i, I suspect that you would want to have two kinds of reset if you go that route. There might be some other insn that may have similar issues. For example, imagine a case where you want to create a merge with a recontructed side branch. First you grow the branch you would merge into, with a sequence: pick A pick B pick C Then in order to reconstruct a side branch that begins from a known point, say the tip of "master", you would want to reset to a commit that is outside of the scope of this rewriting. And then you rebuild that side branch: reset master pick D pick E And finally (and this step shows the beauty of your approach), come back to the other tip and make the merge: reset C merge E Two resets above would have different semantics. The former resets to unwritten, and the latter rewritten. ```