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

David Turner [off-list ref] writes:

quoted

Perhaps an ideal interface might be something like this:

    $ echo HEAD:RelNotes |
      git cat-file --batch='%(objecttype) %(intreemode)
    %(objectsize)' blob 160000 32
    Documentation/RelNotes/2.4.0.txt

I suspect it would be just the matter of teaching "cat-file
--batch" to read from get_sha1_with_context() in
batch_one_object(), instead of reading from get_sha1() which it
currently does.

And that inteferface I think I can live with.

Even if I had %(intreemode), I would still have to do a recursive
search to figure out whether Documentation or RelNotes was a
symlink.

Yes, and why is that a problem?  Think of "cat-file --batch" an
"object server" you query interactively.  You start the process, ask
it about HEAD:RelNotes, and learn that the blob is a link that
points at Documentation/RelNotes/2.4.0.txt.  Then you ask it about
"HEAD:Documentation/RelNotes/2.4.0.txt", which _may_ answer "no such
file", at which point you can start worrying about referring to
places outside the tree (i.e. untracked).

"cat-file" does not know about your project, and especially its
external dependencies, if a symbolic link ever steps outside the
tree objects, better than you do.  Because it is a low-level
plumbing command, allowing it to make policy decisions (e.g. "if
outside repository, always look at the filesystem that the program
happens to be running" [*1*]) is something I would reject as much as
possible.  It will paint us into a corner we cannot later escape out
of.

This is
why I want a follow-symlinks mode.  And since I am already reading
RelNotes, I can (and presently do) parse the mode out of that
data.

mode?  How?  If all you have is an blob object name and no context
around it (i.e. the top-level tree object has that blob with 160000
mode bits), you cannot tell a symlink from a regular file.


[Footnote]

*1* For example, you may have two projects's working trees A and B
    sitting next to each other, and A/sibling may be a symbolic link
    that points at ../B/some/thing.  A Porcelain that uses cat-file
    --batch as "the object server" may notice v1.0:sibling in A's
    history points at ../B/some/thing and would want to grab
    some/thing from the contemporary version of B's commit, instead
    of just blindly going to the filesystem.

On Wed, 2015-04-29 at 14:49 -0700, Junio C Hamano wrote:

David Turner [off-list ref] writes:

quoted

quoted

Perhaps an ideal interface might be something like this:

    $ echo HEAD:RelNotes |
      git cat-file --batch='%(objecttype) %(intreemode)
    %(objectsize)' blob 160000 32
    Documentation/RelNotes/2.4.0.txt

I suspect it would be just the matter of teaching "cat-file
--batch" to read from get_sha1_with_context() in
batch_one_object(), instead of reading from get_sha1() which it
currently does.

And that inteferface I think I can live with.

Even if I had %(intreemode), I would still have to do a recursive
search to figure out whether Documentation or RelNotes was a
symlink.

I apologize.  I have misread your example.  All of my text was assuming
that Documentation/Relnotes/2.4.0.txt was a symlink, instead
of /RelNotes being a symlink to Documentation/Relnotes/2.4.0.txt.  So my
previous message was very difficult to interpret.  I think Jeff King's
reply is a better starting point for discussion, since it lays out the
advantages and disadvantages of the proposal.

allowing it to make policy decisions (e.g. "if
outside repository, always look at the filesystem that the program
happens to be running" [*1*]) 

Despite my confusion, I don't think I ever proposed doing this.  I
proposed that in the case that a symlink points outside the repo,
cat-file would tell the caller that it has done so, so that the caller
can decide what to do.