On Mon, 2015-05-11 at 13:21 -0700, Junio C Hamano wrote: dturner@xxxxxxxxxxxxxxxx writes: > > > +--follow-symlinks:: > > + Follow symlinks inside the repository. 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 repository (e.g. a link to /foo or a > > + root-level link to ../foo), the portion of the link which is > > + outside the repository 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. > > One thing that I found is missing from the above and other places in > the documents updated by this patch, when I pretend that I am an > end-user who never saw the discussion for the problem definition and > design of the solution on the list, is what "symlink" this refers > to and how I am expected to use this feature. > 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. I could also provide some examples, if you think this would be useful. > +If --follow-symlinks is used, and a symlink in the repository points > > +outside the repository, then `cat-file` will ignore any custom format > > +and print: > > + > > +------------ > > +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). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html