On Thu, 19 Jun 2008, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes:
>
> > diff --git a/path.c b/path.c
> > index b7c24a2..790d8d4 100644
> > --- a/path.c
> > +++ b/path.c
> > @@ -294,6 +294,23 @@ int adjust_shared_perm(const char *path)
> > /* We allow "recursive" symbolic links. Only within reason, though. */
> > #define MAXDEPTH 5
> >
> > +const char *make_relative_path(const char *abs, const char *base)
> > +{
> > + static char buf[PATH_MAX + 1];
> > + int baselen;
> > + if (!base)
> > + return abs;
>
> This special case may help the specific caller you have below, but doesn't
> it make the function do more than it advertises with its name?
I don't think so; the best path relative to nothing is the absolute path.
The idea is to return the easiest equivalent path if your pwd is known to
be "base" and you give it an absolute path. If you don't know what your
pwd is, the easiest equivalent path is the absolute path with no symlinks.
Similarly, you get an absolute path if the path you give it isn't inside
base. Maybe "make_brief_path" would be a better name?
> Other than that, I think the change is Ok, but as a "performance tweak",
> it should be backed by some numbers, please?
I was hoping Linus would provide some, since he'd noticed the slowness in
the first place. I'm not sure I have the RAM to have the kernel spend
non-trivial time looking up path elements in an all-cached tree. I'll try
to replicate Linus's test case when I get a chance if he hasn't said
anything.
-Daniel
*This .sig left intentionally blank*
--
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
