Re: RFC: git cat-file --follow-symlinks?

[Jeff King <peff@peff.net>]

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