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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html