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

[James Blackwell]

>     > 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
>

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

Its a little bit different than the idea I meant (grin). In the original
post, I meant something along the lines of 'given a regex, see if
there's one and only one matc'. In the latter post, I intended
something along the lines of 'given a word, check this user generated
list to see if there's an exact match'

That'll play in below.


Tom Lord wrote:
> 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.

I'll hit this one up below.

Tom Lord wrote:
> 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.   

I don't understand what you're trying to say here. As best as I can
tell, you're saying to be careful with the command syntax so that the
regexps setup doesn't unnecessarily overlap possibly valid archive
names. But that's just a guess; I reread your paragraph five times, came
up with five different meanings, and gave up and stuck with #5. :)

Tom Lord wrote:
>
>     > 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      .....
>         ...
[more examples that I brutally cut down in the prime of their lives]

Ok. I think I understand what you mean. You're suggesting that in a
working tree, that there are some built in "aliases" that are calculated
at need. Kind of like half /proc entry / half C macro.

Assuming that's what you mean, I want to call them something else,
because they're not quite the same thing as the aliases we're referring
to on the archive and global level. How about 'argument macros' ? That
would give people a better idea that they're more proactive than people
normally think of as a macro.

I'm not quite sure what feature-a, feature-b and bugfix-a are. Are those
micro branches in disguise? 


Tom Lord wrote:
> 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'm following your idea, generally speaking. As per your examples above,
this is roughly equivilant to listing branches that have been merged
from, correct?

James Blackwell wrote:
>     > I think they're right. This is a better idea than the regexes. 
 
Tom Lord wrote:
> I think it's an orthogonal idea and, roughly, the same one I replied
> to you with.

Yeah, its orthogonal, but I think that in this case, looking for exact
matches is a better thing to do than doing regexps. Imagine the mess
when some lazy bastard starts defining aliases like "ld" for
address@hidden/tla--devo" and jr for
"address@hidden/tla--rbrowse--1.3", and then the user
references address@hidden/torturing--civilians--666,
they'll get surprised to get a copy of rbrowse. Well, unless we're
careful and take extra steps.  For simplicity's sake, I'd rather throw
away the regex part of it and just do some equivilant of
"str_fullymatches". 

James Blackwell wrote:
>     > This idea 
>     > does a great job of solving one of arch's largest complaints -- way too
>     > much typing. 
 
Tom Lord wrote:
> As do your regexp hacks in general.

I think we can get the same thing by doing a series of string
comparisons rather than going through all the effort of pulling the
regex engine in.

James Blackwell wrote:
>     > 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?
>

-t (grin) wrote:
> 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.

As I understood tla fork, that's really just archive-setup + tag in a
handy convienance command. That should work fine with the following
ad-hoc syntax (I know this isn't quite right, but for sake of argument): 
tla fork jr tla--rbrowse-withmerges--1.3.

Regarding tla submit, I'll tell you a sekrit (shhhh). I was kinda truant
during those posts. :)

Ok. Remember how way above I promised to discuss some stuff later?
Welll, about the three levels of aliasing.

I think that having user specified aliases in .arch-params/=aliases
is good, and that having archive specified aliases in =meta-info/=aliases
is good too. As far as which list takes precidence, that'll take some
sit-down-and-think time. I can actually see it *both* ways. Do we look
at the user as having the capability of overriding whats in an archive
(global over archive), or do we conceptually say that the global ones
are the general rule, and individual archives can have exceptions
(archive over global).


-- 
James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400