On mar, 2011-03-15 at 10:02 -0700, Junio C Hamano wrote: > Carlos MartÃn Nieto <cmn@xxxxxxxx> writes: > > > On mar, 2011-03-15 at 12:59 +0100, Carlos MartÃn Nieto wrote: > >> On lun, 2011-03-14 at 15:58 -0700, Junio C Hamano wrote: > >> > Carlos MartÃn Nieto <cmn@xxxxxxxx> writes: > > [...] > >> > > >> > > There is however the extra functionality the function offers, namely > >> > > resolving links. It might be good to split it into two functions so each > >> > > caller can specify what it wants. > >> > > >> > Probably. > >> > >> With the changes mentioned earlier, if you want an absolute pathname, > >> you'd call absolute_path/make_nonrelative_path and if you want to make > >> sure you have the real path of the target file, you'd use real_path just > >> as you'd use realpath on a sane system, with > > > > ... a comment on the functions and maybe some documentation in > > Documentation/techncal, as it doesn't seem to exist yet. > > We probably should involve Nguyán in this thread as his fingers are > everywhere on the codepaths related to setup. > I've been changing this a bit, trying to make all the paths normalized, but it'll take a bit longer. I'll send a partial patch when I've finished something worth seeing (for the moment, the test fail if there is a symlink somewhere in the tree, as I've mixed real_path/make_absolute_path and absolute_path/make_nonrelative_path a bit). Is it a good idea to normalize the paths? Otherwise, everything could be replaced by real_path/make_absolute_path (as most calls already are). As it's transitive and these paths aren't stored permanently (other than with clone), as long as we agree on one representation, it should be fine. Is there a performance hit if we resolve links all the time? If we run everything through normalize_path(_copy), is it slower than resolving links? cmn -- 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