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

[Ron Parker]

On Tue, 13 Jul 2004 14:29:40 -0700 (PDT), Tom Lord <address@hidden> wrote:
> 
> 
> Incidentally, one issue with in-tree aliases is to think through how
> they interact with merging of various sorts.
> 
> One example, you're parent's "parent" alias is different from yours.
> How's that work?  E.g., what if your parent changes his parent alias?
> Does that change to his tree modify your "parent" alias?

I'm not sure in the context of aliases what "you're parent's 'parent'"
would be, but if there is a need to make it explicit, perhaps
:parent:parent. Would make sense. Or parent->parent for the
C++-what-did-my-shell-just-do crowd. (That last part's supposed to be
funny.)

> Another example -- this kind of file:
> 
>   {arch}/=aliases (or whatever):
> 
>        <alias>         <arch-name>
>        <alias>         <arch-name>
>        <alias>         <arch-name>
>        <alias>         <arch-name>
> 
> interacts dubiously with context-based patching.   

Definitely.

> But using multiple files:
> 
>   {arch}/=aliases/:
> 
>        file:                     contents:
> 
>     {arch}/=aliases/<alias>    <arch-name>
>     {arch}/=aliases/<alias>    <arch-name>
>     {arch}/=aliases/<alias>    <arch-name>
>     ....
> 
> can at least avoid conflicts -- but is it the right semantic?

Performance could bite on Windows, but other than that, it is
certainly reduces merge issues. There's something niggling at the back
of my mind that this is almost right but just missing something.
*smack* *smack* No, it's not going to come out right now. Part of what
bothers me is that it is just sparse, one alias per file. That may not
be all that bad, at least each file would not have to be opened and
read, only the one that is actually used.  It does simplify
tab-completion in some respects.

I seem to be is stupid question/comment mode today, so here's another.

It bares at least some resemblance to the contents of the configs
directory.  Might there be some use for per-config aliases that are
maintained out of tree, or in parallel with the configs?  What if
build-config could also dump a =config-aliases file or something akin
to the =RELEASE-ID file. Then those aliases could be used across the
nested trees for the purpose of project-level aliases, assuming that
config-level is what you meant by project aliases in a separate mail.

Potentially this would allow the use of the same alias to merge
against a given archive in both the src/hackerlab and src/tla
directories.