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.
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 also propose that we use Linux's limit of 40 symlinks by default, but
--follow-symlinks could also have =max_links_to_follow to adjust this if
anyone cares)
Do people think this is reasonable? If so, I'll see if I can get some
time to work on it this month.
Hi,
David Turner wrote:
Instead, it would be cool if cat-file had a mode in which it would
follow symlinks.
Makes sense.
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].
What happens when the symlink payload contains a newline?
Thanks,
Jonathan
On Wed, 2015-04-29 at 14:16 -0700, Jonathan Nieder wrote:
Hi,
David Turner wrote:
quoted
Instead, it would be cool if cat-file had a mode in which it would
follow symlinks.
Makes sense.
quoted
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].
What happens when the symlink payload contains a newline?
Oh, right.
So, how about [sha] "symlink" [bytes] "\n" [target] instead?
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@alum.mit.edu