On Thu, Apr 30, 2015 at 12:04:10PM +0200, Andreas Schwab wrote:
> Jeff King <peff@xxxxxxxx> writes:
>
> > 4. Return the last object we could resolve, as I described. So
> > foo/bar/baz (with "../../../external" as its content) in this case.
> > When you resolve a name, you can ask for the context we discovered
> > along the way by traversing the tree. The mode is one example we've
> > already discussed, but the path name is another. So something like:
> >
> > echo "HEAD^{resolve}:fleem" |
> > git cat-file --batch="%(objectname) %(size) %(intreepath)"
> >
> > would show:
> >
> > 1234abcd 17 foo/bar/baz
> > ../../../external
> >
> > And then the caller knows that the path is not relative to the
> > original "fleem", but rather to "foo/bar/baz".
>
> Note that ".." will always follow the *physical* structure, so if
> foo/bar/baz is walking over symbolic links, "../../.." may lead you to
> somewhere else entirely.
True. I had not considered that, as git does not walk over such symlinks
at all currently. But presumably one would want it to to implement this
kind of "follow symlink" logic. IOW, we cannot just look up
"foo/bar/baz" in the first place, as that may not even exist in the
tree; we may need to realize that "foo" is a symlink and resolve that
first, then find "bar/baz" in the destination.
Which means that I think this has to be implemented as part of the name
resolution (i.e., the "^{resolve}") proposal. cat-file could not say:
get_sha1_with_context("HEAD:foo/bar/baz", sha1, &ctx);
if (S_ISLNK(ctx.mode))
... resolve ...
The initial get_sha1 would fail if "foo" is a symlink. Likewise, one
cannot implement this by querying cat-file repeatedly without asking for
each leading prefix (so ask for "HEAD:foo", see if it's a link, then
"HEAD:foo/bar", etc).
Of course it does not _have_ to be part of the normal get_sha1 name
resolution. But if not, it would have to reimplement the tree-walking
part of that name resolution.
Thanks for giving another interesting case to consider.
-Peff
--
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