Re: [PATCH] Use nonrelative paths instead of absolute paths for cloned repositories

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Thu, 5 Jun 2008, Daniel Barkalow wrote:
>
>> Particularly for the "alternates" file, if one will be created, we want 
>> a path that doesn't depend on the current directory, but we want to 
>> retain any symlinks in the path as given and any in the user's view of 
>> the current directory when the path was given.
>
> I have to say that I do not follow why the symlinks should be trusted any 
> more than the absolute paths.

Thanks, Daniel.

I am obviously in favor of fixing this regression before 1.5.6, and the
introduction of make_nonrelative_path() for the use of clone alone is
probably the least impact and safe solution in the short term after -rc1.

In the longer term, we would inevitably face "when should one use
nonrelative and when should one use absolute?" and we would eventually
have to answer it.  It may turn out that many current users of "absolute"
are better off using "nonrelative", but I suspect we won't get rid of
"absolute" completely, because one of the reasons it avoids symlinks at
great lengths is so that it can check the containment relationships
between paths reliably (e.g. "is this path outside the repository, in
which case we should refuse to add it to the index, and we use --no-index
without being asked when running "diff"").

But using "absolute" for containment comparison is one thing.  Storing the
result of "absolute" is quite another.

We've already learned to love a similar crazyness somebody's system has on
this list.  If you want to check if the user string is equivalent to a
path you stored in the filesystem, you compare them after normalizing and
that is a sensible approach.  Storing path after normalizing, which would
be different form than what the user originally used to create, is not so
sane and leads to all sorts of pain.  Ending up storing the output from
"absolute" in info/alternates is just like giving normalized sequence back
from readdir(3) on such a system.