Re: [Gnu-arch-users] Re: Default version for star-merge (and more)

[Tom Lord]

    > From: address@hidden (James Blackwell)

    [regexp foo pros and cons]

    > What's more, Christian and Aaron told me of a much more interesting
    > idea -- version aliases. Basically, the idea goes something like this
    > (I'm filling in a few holes)

    > In .arch-params/=aliases/ one will find files with names similiar to
    > these: 

    > name:             contains:
    > blacky-rbrowse    address@hidden/tla--rbrowse--1.3
    > tladevo           address@hidden/tla--devo
    > lord              address@hidden
    > oldlord           address@hidden

I don't see any big contradction here.  That's close to where I
thought your idea went but not quite the same.

I think we _also_ want those aliases per-project and per-working-tree.
Indeed: I'd give per-project, not per-user the highest priority.

And then, with those aliases in place, I think we want your regexps to 
apply with, yeah (duh), care to keep the syntax unambiguous.   We've
been over instances of the name-ambiguity problem often enough that I
didn't try to solve it here and just assumed that between now and
final design that'd be solved.   


    > This would allow things like "tla rbrowse lord", "tla get
    > blacky-rbrowse" and "tla star-merge tladevo"

And, with per-tree aliases, it would allow:

        % cd $project_tree
        % tla related
        upstream        address@hidden/hack--mainline--1.0
        feature-a       .....
        feature-b       .....
        bugfix-a        .....
        ...

and

        % tla related /feature/   # or whatever syntax
        feature-a       ...
        feature-b       ...


and 

        % tla missing -n /feature/
        * missing from feature-a
        [usual `missing output']
        * missing from feature-b
        [usual `missing output']
        ....

etc.

The general idea is that where users want to make graphs of related
branches with an expected patch flow between them, let's "reify" (make
a first-class representation of) those graphs and beef-up commands to
help navigate them.


    > I think they're right. This is a better idea than the regexes. 

I think it's an orthogonal idea and, roughly, the same one I replied
to you with.


    > This idea 
    > does a great job of solving one of arch's largest complaints -- way too
    > much typing. 

As do your regexp hacks in general.


    > I'm more than happy to dive into the code and throw up for debate the best
    > two or three ways to handle this, and then implement the winner.

    > What do you guys say?

As preliminary investigation, that could be quite valuable.

Before a final installation, we should not necessarily solve but at
least have very good confidence about how this can related to things
like a `fork' or `submit' command.

-t