On 5/4/07, Alex Riesen <raa.lkml@xxxxxxxxx> wrote:
On 5/4/07, Dana How <danahow@xxxxxxxxx> 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@xxxxxxxxx +1 650 804 5991 cell
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html