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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> 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.

Me neither, but if I really had to pick one, it would be the last
one, except that %(intreepath) would have to be somehow quoted,
perhaps like how the output from "git diff" quotes funny pathnames.

When we want to use this as an extended SHA-1 syntax (i.e. outside
of "cat-file --batch"), it most likely should just error out if the
link does not resolve to a path that would eventually result in an
in-tree object, with the same error message you would get when you
ask for the object name for "HEAD:no-such-path".

But stepping back a bit.

We have been talking about HEAD^{resolve}:fleem but how did we learn
that there is a path "fleem" in the tree of HEAD in the first place?
I would presume that the answer eventually boils down to "somebody
fed HEAD to 'ls-tree -r'", and then that somebody is an idiot if it
did not grab the mode bits to learn what kind of blob fleem is, or
if it did not tell the guy that wants to drive "cat-file --batch".

So this whole thing somehow starts to smell like a solution that is
looking for a problem that has arisen only because the use case
story behind it is screwy.  Again, why is it such a huge problem to
make it relative and ask a newly formlated question for the guy who
is driving "cat-file --batch" in the first place?