Re: [PATCH] Support ent:relative_path

["Alex Riesen" <raa.lkml@gmail.com>]

On 5/4/07, Dana How <danahow@gmail.com> wrote:
> > > 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 .]

Ack

> (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 "/".

And new semantics, if possible

> (d) We are left with the following patterns:
>      1. :string

Probably breaks something

>      2. :/string

Taken

>      3. ://string

Ugly (and breaks tab completion)

> [ 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 / ?

How often should they start to justify any decision?

> II. Make :/string a full path, and ://string match ^string .
>    Is changing the current :/string to ://string less painful/dangerous?

Johannes?

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

Very/

> Do you use :/string now?  Since it's a case-sensitive exact match,

No. It just exists, AFAICS

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

I think, I'd be convinced by this one too, if not for "//" making
no sense anywhere but root accidentally typed twice.
I'd even sacrifice (or change) the search syntax for good.