On Wed, Apr 29, 2015 at 06:45:45PM -0700, David Turner wrote:
> On Wed, 2015-04-29 at 21:16 -0400, Jeff King wrote:
> > On Wed, Apr 29, 2015 at 06:06:23PM -0700, David Turner wrote:
> > 3. Ditto for out-of-tree. Note that this would be the _raw_ symlink
> > contents, not any kind of simplification (so if you asked for
> > "foo/bar/baz" and it was "../../../../out", you would the full path
> > with all those dots, not a simplified "../out", which I think is
> > what you were trying to show in earlier examples).
>
> Unfortunately, we need the simplified version, because we otherwise
> don't know what the ..s are relative to in the case of a link to a link:
>
> echo content >dest ;# actual blob
> mkdir -p foo/bar
> ln -s foo/bar/baz fleem # in-tree link-to-link
> ln -s ../../../external foo/bar/baz # out-of-tree link
>
> If echo HEAD^{resolve}:fleem were to return ../../../external (after
> following the first symlink to the second), we would have lost
> information.
Urgh, yeah, thanks for the counter-example.
Here are some possible alternatives:
1. If we can't resolve fully, don't resolve anything. I.e., return the
"fleem" object here, and the caller can recurse if they want. This is
simple and correct, but not as helpful to somebody who wants to follow
the out-of-tree link (they have to re-traverse the fleem->foo/bar/baz
link themselves).
2. Consider it can error if resolution fails. If you ask for
"HEAD^{tree}^{commit}", that does not resolve to anything (because
we can't peel the tree to a commit). Like (1), this is simple and
correct, but probably not all that helpful. The caller has to
start from scratch and resolve themselves, rather than getting an
intermediate result.
3. Return an object with the symlink relative to the original
filename (so "../external" in this case). This is kind of weird,
though, because we're not just returning a string from the name
resolution. It's an actual object. So we'd be generating a fake
object that doesn't actually exist in the object db and
returning that. Feeding that sha1 to another program would fail.
4. Return the last object we could resolve, as I described. So
foo/bar/baz (with "../../../external" as its content) in this case.
When you resolve a name, you can ask for the context we discovered
along the way by traversing the tree. The mode is one example we've
already discussed, but the path name is another. So something like:
echo "HEAD^{resolve}:fleem" |
git cat-file --batch="%(objectname) %(size) %(intreepath)"
would show:
1234abcd 17 foo/bar/baz
../../../external
And then the caller knows that the path is not relative to the
original "fleem", but rather to "foo/bar/baz".
The problem is that although this context lookup is already part of
get_sha1_with_context, that is not exposed through every interface.
E.g., "git rev-parse HEAD^{resolve}:fleem" will give you an object,
but you have no way of knowing the context.
I can't say that I'm excited about any of them. Perhaps you or somebody
else can think of a more clever solution.
Note that the complication with (3) does come from my trying to push
this down into the name-resolution code.
-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