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

> On Wed, Apr 29, 2015 at 06:45:45PM -0700, David Turner wrote:
> 
> > On Wed, 2015-04-29 at 21:16 -0400, Jeff King wrote:
> > > On Wed, Apr 29, 2015 at 06:06:23PM -0700, David Turner wrote:
> > >   3. Ditto for out-of-tree. Note that this would be the _raw_ symlink
> > >      contents, not any kind of simplification (so if you asked for
> > >      "foo/bar/baz" and it was "../../../../out", you would the full path
> > >      with all those dots, not a simplified "../out", which I think is
> > >      what you were trying to show in earlier examples).
> > 
> > Unfortunately, we need the simplified version, because we otherwise
> > don't know what the ..s are relative to in the case of a link to a link:
> > 
> >   echo content >dest ;# actual blob
> >   mkdir -p foo/bar
> >   ln -s foo/bar/baz fleem             # in-tree link-to-link 
> >   ln -s ../../../external foo/bar/baz # out-of-tree link
> > 
> > If echo HEAD^{resolve}:fleem were to return ../../../external (after
> > following the first symlink to the second), we would have lost
> > information.
> 
> Urgh, yeah, thanks for the counter-example.
> 
> Here are some possible alternatives:
> 
>   1. If we can't resolve fully, don't resolve anything. I.e., return the
>      "fleem" object here, and the caller can recurse if they want. This is
>      simple and correct, but not as helpful to somebody who wants to follow
>      the out-of-tree link (they have to re-traverse the fleem->foo/bar/baz
>      link themselves).
> 
>   2. Consider it can error if resolution fails. If you ask for
>      "HEAD^{tree}^{commit}", that does not resolve to anything (because
>      we can't peel the tree to a commit). Like (1), this is simple and
>      correct, but probably not all that helpful. The caller has to
>      start from scratch and resolve themselves, rather than getting an
>      intermediate result.
> 
>   3. Return an object with the symlink relative to the original
>      filename (so "../external" in this case). This is kind of weird,
>      though, because we're not just returning a string from the name
>      resolution. It's an actual object.  So we'd be generating a fake
>      object that doesn't actually exist in the object db and
>      returning that. Feeding that sha1 to another program would fail.
> 
>   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".
> 
>      The problem is that although this context lookup is already part of
>      get_sha1_with_context, that is not exposed through every interface.
>      E.g., "git rev-parse HEAD^{resolve}:fleem" will give you an object,
>      but you have no way of knowing the context.
> 
> I can't say that I'm excited about any of them. Perhaps you or somebody
> else can think of a more clever solution.
> 
> Note that the complication with (3) does come from my trying to push
> this down into the name-resolution code.