Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. -- 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
