Re: [PATCH] Support ent:relative_path

["Dana How" <danahow@gmail.com>]

On 5/4/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 5/4/07, Dana How <danahow@gmail.com> wrote:
> > > I'd suggest to define a special character for _top_ level. Real pity
> > > ":/" is taken.
> > We could use ://fullpath for top level,
>
> No good. How'd you find a commit starting with "/" than? (without
> changing ":/" syntax).
Oh blechh.  get_sha1_oneline uses prefixcmp(), not strstr().
Are there are any commits in git or the kernel starting with "/" ?

> > and :relpath for relative. Then "string" in :/string couldn't start with /,
> > which shouldn't be a problem (right?).  I've certainly seen double
> > slashes before;
> > perforce in fact uses them for the root of the repository (depot).
>
> And I really hate perforce for its stupid redundancy (and changing of
> meaning of well-known idioms: why should // be anything special
> but plain top level or root?! Why the hell do they need them at if
> you cannot use relative paths in client specs at all?! Why can't the
> p4 command-line tool figure the fact from context or request the
> context be provided by user?! IOW, Perforce is a real bad example
> of how you do version control).
Whoa!  I'm stuck using perforce too; I'm not holding it up as a *big*
example.  I originally saw // meaning root in the Apollo DOMAIN
system,  so for that reason it makes sense to me.  I think it also
means network root in Windoze (well, \\ does ;-) )..

> > This all depends on deciding that :relpath should be the (incompatible)
> > new default, and I'm not sure that's going to happen.
>
> If we are to stay that compatible, maybe ":./" for relative paths and the
> old syntax left to mean top-level would the best choice for now.

Let's summarize so far:  I think everyone's convinced me we need
to be careful,  so this email will be more tedious than I'd like.

(a) :./relpath clearly inidicates relative path. [Also take :../relpath .]
(b) I'd like a more natural way to do :./relpath (e.g. :relpath),
     or at least a future path to such.
(c) We would like to avoid new special characters beyond ":".
     This means everything has to be done with "." and "/".
(d) We are left with the following patterns:
     1. :string
     2. :/string
     3. ://string

[ We need a clear way to say relative, a clear way to say absolute,
and the current :string can change from absolute to relative some time
in the future if we so decide. ]

Ideas for (d) 2&3:
I. Make :/string actually match the RE ^[/]*string,  and ://string a full path.
   The leading [/]* is a very small change to get_sha1_oneline().
   [Or change prefixcmp() to strstr() in get_sha1_oneline().]
   How often do commit messages start with / ?
II. Make :/string a full path, and ://string match ^string .
   Is changing the current :/string to ://string less painful/dangerous?
III. Make :/string match ^string when string has no slashes,
    :/string a full path when string does have slashes,
    and ://string match ^string . Hmm,  seems confusing.
Do you use :/string now?  Since it's a case-sensitive exact match,
I don't think I'd even use it.
I find idea (II) most natural: absolute paths have one /,
and string matches have 2 suggesting an RE.

Concerning the current :string , perhaps we could do the following.
There would be 2 internal fixed mode variables (NOT config variables) which
do the following.  The first controls whether this means an absolute
or relative path.  The second controls whether a warning message
is printed whenever the first is consulted to make a decision.  The
interpretation of :string is left as-is, but motivated janitors (like me
in this case) can use the second mode variable to change all
:string patterns to :/string or ://string in scripts,   letting us
switch over later
by changing one mode variable.

Someone mentioned DWIM for :string -- check both absolute and relative,
in that order for compatibility probably.  This seems a messy
definition to me.  Comments?

Anyway,  this is more involved than I'd hoped,
but it's good to think about consequences.

Thanks,
-- 
Dana L. How  danahow@gmail.com  +1 650 804 5991 cell