Jeff King <peff@xxxxxxxx> writes:
> Which means that I think this has to be implemented as part of the name
> resolution (i.e., the "^{resolve}") proposal. cat-file could not say:
>
> get_sha1_with_context("HEAD:foo/bar/baz", sha1, &ctx);
> if (S_ISLNK(ctx.mode))
> ... resolve ...
>
> The initial get_sha1 would fail if "foo" is a symlink. Likewise, one
> cannot implement this by querying cat-file repeatedly without asking for
> each leading prefix (so ask for "HEAD:foo", see if it's a link, then
> "HEAD:foo/bar", etc).
>
> Of course it does not _have_ to be part of the normal get_sha1 name
> resolution. But if not, it would have to reimplement the tree-walking
> part of that name resolution.
>
> Thanks for giving another interesting case to consider.
Yup, everything above makes sense, and I think it is an argument for
making this new feature as part of the sha1-name infrastructure, if
only that it has to do some sort of tree-walking already anyway.
Thanks.
--
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