Re: RFC: git cat-file --follow-symlinks?

From: Jeff King <peff@peff.net>
Date: Apr 30, 2015, 18:27 UTC
Message-ID: <20150430182659.GB23431@peff.net>
In-Reply-To: <87383ihqzp.fsf@igel.home>

On Thu, Apr 30, 2015 at 12:04:10PM +0200, Andreas Schwab wrote:

Show 22 quoted lines

> Jeff King <peff@peff.net> 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