On Fri, May 01, 2015 at 10:29:15AM -0700, David Turner wrote:
> > > 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.
> >
> > Yes, agreed (my list was written before Andreas brought up the idea of
> > symlinks in the intermediate paths). I think to let the caller pick up
> > where you left off, you would have to create a new string that has the
> > "remainder" concatenated to it.
>
> Since that new string does not exist in the object db, isn't that pretty
> much proposal 3? We could, in this case, provide a fake sha as well
> ("0"*40), to make it clear that the object does not exist.
Yes, I think it is the same as proposal 3. Complete with all of the
fake-object awkwardness. I'm not sure I like the fake-sha1 idea. The
general pattern for accessing an object is:
1. Turn some user-provided name into an object (get_sha1).
2. Retrieve that object content (read_sha1_file).
By pushing the symlink resolution into step 1, it "just works"
everywhere. But if we hand back a fake sha1, now every call-site has to
be aware of it.
I think the solutions range from:
a. Put resolution in get_sha1. Return an error when we can't
resolve. Callers are on their own to do anything else.
b. Put resolution in get_sha1. If we can't resolve, return an error.
If the _with_context variant is called, leave our partial result
string there. Some callers may choose to expose that information
(e.g., cat-file might), at which point the user can "pick up" where
git leaves off for out-of-tree links.
c. Forget about get_sha1. This gets implemented elsewhere (e.g., as a
cat-file feature as you originally proposed).
Certainly (a) is tempting and simple, but my understanding of your use
case is that you would like to follow out-of-tree links.
It seems like (b) is the most flexible, in the sense that it would
solve your case, and allows "git rev-parse HEAD^{resolve}:foo" when the
result is well-formed inside the repository. But I wonder if it's
actually worth the complexity. Without exposing the information for the
user to continue the traversal, it seems like only half a solution for
those parts of the code. And we still have to design some kind of custom
output for cat-file to expose the context.
So maybe (c) really is the simplest way forward. I dunno. I know that's
coming full circle to your original proposal. Hopefully that isn't too
infuriating for you. ;)
-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