Show 24 quoted lines
> Carlos Martín Nieto <cmn@elego.de> 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@elego.de> 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
Carlos Martín Nieto <cmn@elego.de>