Re: RFC: git cat-file --follow-symlinks?
- From
Jeff King <peff@peff.net>
- Date
- Apr 30, 2015, 00:37 UTC
- Message-ID
- <20150430003750.GA4258@peff.net>
- In-Reply-To
- <20150429231150.GB3887@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/barwhich 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