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

David Turner [off-list ref] writes:

I'll send something like this when I re-roll:

Follow symlinks inside the repository when requesting objects with
extended SHA-1 expressions of the form tree-ish:path-in-tree. Instead of
providing output about the link itself, provide output about the
linked-to object.  This option requires --batch or	--batch-check.  In
the event of a symlink loop (or more than 40 symlinks in a symlink
resolution chain), the file will be treated as missing.  If a symlink
points outside the tree-ish (e.g. a link to /foo or a root-level link
to ../foo), the portion of the link which is outside the tree will be
printed. Follow-symlinks will be silently turned off if <object>
specifies an object in the index rather than one in the object database.

Very understandable. I like it.

I could also provide some examples, if you think this would be useful.

That may not be a bad idea.

quoted

quoted

+symlink SP <size> LF <symlink> LF
+------------

A symlink contain LF, obviously, and we should use some quoting
convention.  Perhaps quote_c_style() on a string that needs it is
sufficient---most sane people do not put LF or literally '\' 'n' or
'"' in their symbolic links, so the ugly output is not visible for
them, and it is far better to be able to say "If you have funny
characters in your symlinks, they will be quoted" than "If you have
funny characters in your symlinks, you are SOL".

There is no need for quoting because <size> is sufficient to
disambiguate the parsing (just as is the case for blobs, which might
contain arbitrary characters).

OK.  That is a very sensible way to think about it.

I briefly wondered if trailing LF is a healthy thing, but blob
output also gives an extra LF after <contents> (i.e. the reader of
"<name> SP blob SP <size> LF <contents> LF" must skip (size + 1)
bytes to get to the next record), so it is consistent.

Thanks.