Re: [PATCH v4 3/3] cat-file: add --follow-symlinks to --batch
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 11, 2015, 22:39 UTC
- Message-ID
- <xmqqtwvi20y5.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <1431383471.15048.9.camel@ubuntu>
David Turner <dturner@twopensource.com> writes:
Show 12 quoted lines
> 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.
Show 14 quoted lines
>> > +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.