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

[Jeff King <peff@peff.net>]

On Wed, Apr 29, 2015 at 07:11:50PM -0400, Jeff King wrote:

> Yeah, I agree if you let git punt on leaving the filesystem, most of the
> complicated problems go away. It still feels a bit more magical than I
> expect out of cat-file, and there are still corner cases (e.g., do we do
> cycle detection? Or just have a limit to the recursion depth?)

I was pondering the "magical" above. I think what bugs me is that it
seems like a feature that is implemented as part of one random bit of
plumbing, but not available elsewhere.

Conceptually, this is like peeling object names. You may give a tag
name, but if you ask for a tree commit we will peel the tag to a commit,
and the commit to a tree. This is sort of the same thing; you give a
path within a tree, and we will peel until we hit a "real" non-symlink
object.

I don't know what the syntax would look like. To match "foo^{tree}" it
would be something like:

  HEAD:foo/bar^{resolve}

or something like that. Except that it is a bad idea to allow "^{}"
syntax on the right-hand side of a colon, as it is ambiguous with
filenames that contain "^{resolve}". So it would have to look something
like:

  HEAD^{resolve}:foo/bar

which is a _little_ weird, but actually kind of makes sense. The
"resolve" operation inherently is not just about the filename, but about
uses HEAD^{tree} as the root context.

So I dunno. This pushes the resolving logic even _lower_ in the stack
than it would be in cat-file. So why do I like it more? Cognitive
dissonance? I guess I the appeal to me is that it:

  1. Makes the concept available more generally (you can "rev-parse" it,
     you can "git show" it, etc). It also lets you _name_ the object in
     question, so you can ask for other things besides it contents (like
     its name, its type, etc).

  2. Positions it alongside other peeling name-resolution functions.

Thoughts?

-Peff