On Wed, 2015-04-29 at 23:37 -0400, Jeff King wrote:
> 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.
Actually, I think 4 has an insurmountable problem. Here's the case I'm
thinking of:
ln -s .. morx
Imagine that we go to look up 'morx/fleem'. Now morx is the "last
object we could resolve", but we don't know how much of our input has
been consumed at this point. So consumers don't know that after they
exit the repo, they still need to find fleem next to it.
--
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