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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 29, 2015, 21:49 UTC
Message-ID: <xmqqh9ry4nbx.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1430343059.14907.18.camel@ubuntu>

David Turner <dturner@twopensource.com> writes:

Show 17 quoted lines

>> 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.