On 04/29/2015 10:57 PM, David Turner wrote:
> I recently had a situation where I was using git cat-file (--batch) to
> read files and directories out of the repository -- basically, todo the
> equivalent of open, opendir, etc, on an arbitrary revision.
> Unfortunately, I had to do a lot of gymnastics to handle symlinks in the
> repository. Instead of just doing echo $SHA:foo/bar/baz | git cat-file
> --batch, I would have to first check if foo was a symlink, and if so,
> follow it, and then check bar, and so on.
>
> Instead, it would be cool if cat-file had a mode in which it would
> follow symlinks.
I guess it's obvious, but I haven't seen it discussed in this thread, so
I wanted to point out that this feature has some limitations related to
how its arguments are constructed.
In the examples discussed,
git cat-file --follow-symlinks $committish:foo/bar/baz
, we know the root of a tree and we know the relative path where the
symlink was located, so all is well (modulo a policy for handling
symlinks that point outside of the repo). But the following, which would
naively seem to be identical, cannot work:
oid=$(git rev-parse $committish:foo/bar/baz)
git cat-file --follow-symlinks $sha1
The problem is that `$oid` is the name of a blob, and `cat-file` can't
know whether the blob represents the contents of a symlink or the
contents of a file. (And even if it knew, it would have no idea what
tree the symlink paths should be interpreted relative to.) What if we
pass `cat-file` a tree and a relative path instead?:
tree=$(git rev-parse $committish:foo/bar)
git cat-file --follow-symlinks $tree:baz
Now it can work, but only if the symlink chain never rises above the
level of `$tree`. So for example, if `foo/bar/baz` points at `../xyzzy`,
then the very first example would succeed, whereas the last one would
have to fail. Please note that there is no possible way to avoid failure
by reading files from the filesystem outside of the repository, because
in this case `cat-file` can have no idea where to look.
> The major wrinkle is that symlinks can point outside the repository --
> either because they are absolute paths, or because they are relative
> paths with enough ../ in them. For this case, I propose that
> --follow-symlinks should output [sha] "symlink" [target] instead of the
> usual [sha] "blob" [bytes]. Since --follow-symlinks is new, this format
> change will not break any existing code.
> [...]
I don't think this is doable in the general case, because it is not only
the last component of the path that can point outside of the repository.
Suppose we have
foo -> ../plugh
and I run
git cat-file --follow-symlinks HEAD:foo/bar/baz
The lookup of `foo` already falls outside of the repository, and
`bar/baz` is relative to *it*, so in this case it would have to return
???? "symlink" ../plugh/bar/baz
The question is, what SHA-1 should be output in place of the question
marks? The only SHA-1 we have handy is the SHA-1 of `foo`, but that
doesn't seem especially useful.
Michael
--
Michael Haggerty
mhagger@xxxxxxxxxxxx
--
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