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

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