Subject: Re: What's cooking in git.git (topics)

From: Jon Loeliger <[email-masked]>
Date: Fri, 30 May 2008 16:10:52 -0500

Junio C Hamano wrote:
> Here are the topics that have been cooking.  Commits prefixed
> with '-' are only in 'pu' while commits prefixed with '+' are
> in 'next'.
> 
>
> * js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
>  + Use perl instead of tac
>  + Fix t3404 assumption that `wc -l` does not use whitespace.
>  + rebase -i: Use : in expr command instead of match.
>  + rebase -i: update the implementation of 'mark' command
>  + Add option --preserve-tags
>  + Teach rebase interactive the tag command
>  + Add option --first-parent
>  + Do rebase with preserve merges with advanced TODO list
>  + Select all lines with fake-editor
>  + Unify the length of $SHORT* and the commits in the TODO list
>  + Teach rebase interactive the merge command
>  + Move redo merge code in a function
>  + Teach rebase interactive the reset command
>  + Teach rebase interactive the mark command
>  + Move cleanup code into it's own function
>  + Don't append default merge message to -m message
>  + fake-editor: output TODO list if unchanged
> 
> This may complement the proposed "sequencer" GSoC project.  Dscho seems to
> have quite a strong objection to the 'mark' syntax and mechanism being
> unnecessarily complex.  Let's wait and see if a less complex but equally
> expressive alternative materializes...

Well, there are the two not-quite facetious suggestions
I made off list to Junio.  Granted, he though they would
be overkill (too), but I guess I could make them here for
the general record in any case.

One suggestion was to make a procedural model out of
the commit graph and allow something like this:

    b :- pick(B)
    x :- merge(pick(A), b)
    y :- merge(pick(C), b)
    z :- merge(x, y)

My second and semi-equivallent suggestion was to
allow a lisp-like notation:

    (merge (merge (pick A)
                  (pick B)
           (merge (pick B)
                  (pick C)

As Junio observed, even that could be beyond what most
casual git rebase -i users are willing to do to a sequencer
edit stream before getting down to business.

Ah well. :-)

jdl