Re: [PATCH v5 3/3] cat-file: add --follow-symlinks to --batch

Junio C Hamano [off-list ref] writes:

Ahh, that would also give us "missing", so in that sense you are
being consistent.

But I do not think that consistency is useful.  Showing just
"missing" instead is losing information and that is what bothers me.

Showing "symlink 6 nosuch" to this "link points at a target that
would be in-tree but there is no such object in the tree" symbolic
link instead of "missing" would make it more useful, and I do not
offhand think of a downside, but maybe I am missing something.

For a link that points outside, the code already gives

    $ ln -s ../outside outlink
    $ git add outlink
    $ echo "$(git write-tree):outlink" |
      git cat-file --batch --follow-symlinks

"symlink ../outside", so the script reading from the batch output
already has to be prepared to handle "symlink" and understand it as
saying "the link does not point an object that is inside the tree".

Having said all that, I think we can make readers' life easier by
classifying various reasons why --follow-symlinks cannot pretend
as if the in-tree pointee were given as its input and signal it
differently:

 * A link points outside the original tree (or the index, once we
   support "cat-file :RelNotes").

   I think your "symlink <size> LF <target> LF" already does this.

 * A link points (directly or indirectly) at itself.

   This would be your "loop <size> LF <target> LF", which I think is
   good.

 * A link does not step outside the original tree, but the pointee
   does not exist in the original tree.

   I think you currently say "<object name for HEAD:link> missing",
   but I do not think it is useful.  That object does exist, but it
   merely cannot be dereferenced.  Perhaps introducing a new one,
   e.g. "dangling <size> LF <target> LF" similar to symlink/loop,
   would help the reader better?

Are there other cases?  The only other case I think of is when the
link resolves cleanly inside the tree, which you already handle.

Thanks.