From: Junio C Hamano <gitster@pobox.com>
To: David Turner <dturner@twopensource.com>
Cc: git@vger.kernel.org, David Turner <dturner@twitter.com>
Subject: Re: [PATCH v4 3/3] cat-file: add --follow-symlinks to --batch
Date: Mon, 11 May 2015 15:39:46 -0700 [thread overview]
Message-ID: <xmqqtwvi20y5.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1431383471.15048.9.camel@ubuntu> (David Turner's message of "Mon, 11 May 2015 18:31:11 -0400")
David Turner <dturner@twopensource.com> 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.
>> > +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.
prev parent reply other threads:[~2015-05-11 22:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-11 17:56 (unknown), dturner
2015-05-11 17:56 ` [PATCH v4 1/3] tree-walk: learn get_tree_entry_follow_symlinks dturner
2015-05-11 17:56 ` [PATCH v4 2/3] sha1_name: get_sha1_with_context learns to follow symlinks dturner
2015-05-11 19:42 ` Junio C Hamano
2015-05-11 17:56 ` [PATCH v4 3/3] cat-file: add --follow-symlinks to --batch dturner
2015-05-11 20:21 ` Junio C Hamano
2015-05-11 22:31 ` David Turner
2015-05-11 22:39 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqtwvi20y5.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=dturner@twitter.com \
--cc=dturner@twopensource.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.