threads / rfc / 13097

patch, 10 partsRe: [PATCH/RFC 01/10] Teach rebase interactive the mark command

Subject: Re: [PATCH/RFC 01/10] Teach rebase interactive the mark command

## tl;dr

4 messages between Apr 13, 2008 and Apr 15, 2008. Diffs are folded; open one to read it.

replies: 3people: 4as markdown or json

Paul Fredrickson· Apr 13, 2008, 20:51 UTC · lore
Show 24 quoted lines
> Jrg Sommer <joerg@alea.gnuu.de> 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· Apr 14, 2008, 09:27 UTC · re: Paul Fredrickson · lore
Hello Paul,
Paul Fredrickson schrieb am Sun 13. Apr, 13:51 (-0700):
Show 17 quoted lines
> > Jrg Sommer <joerg@alea.gnuu.de> 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· Apr 14, 2008, 14:10 UTC · re: Paul Fredrickson · lore
Hi,
On Sun, 13 Apr 2008, Paul Fredrickson wrote:
Show 14 quoted lines
> > Jrg Sommer <joerg@alea.gnuu.de> 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/<original-commit-name>.

I really do not like complicating things unnecessarily.

Ciao, Dscho

Junio C Hamano· Apr 15, 2008, 00:11 UTC · re: Johannes Schindelin · lore
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 11 quoted lines
> 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.

← back to recent threads