git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
May 12, 2015, 20:22 UTC
Message-ID
<xmqqd225fsw8.fsf@gitster.dls.corp.google.com>
In-Reply-To
<xmqqlhgtftw0.fsf@gitster.dls.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
Show 21 quoted lines
> 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.
Previous: Junio C HamanoNext: David Turner
Message 12 of 20 in “cat-file --follow-symlinks”
  1. 0/3 cat-file --follow-symlinksdturner@twopensource.com, May 11, 2015
  2. 1/3 tree-walk: learn get_tree_entry_follow_symlinksdturner@twopensource.com, May 11, 2015
  3. Johannes SixtMay 12, 2015
  4. 2/3 sha1_name: get_sha1_with_context learns to follow symlinksdturner@twopensource.com, May 11, 2015
  5. 3/3 cat-file: add --follow-symlinks to --batchdturner@twopensource.com, May 11, 2015
  6. Johannes SixtMay 12, 2015
  7. Junio C HamanoMay 12, 2015
  8. David TurnerMay 12, 2015
  9. Junio C HamanoMay 12, 2015
  10. David TurnerMay 12, 2015
  11. Junio C HamanoMay 12, 2015
  12. Junio C HamanoMay 12, 2015
  13. David TurnerMay 12, 2015
  14. Junio C HamanoMay 12, 2015
  15. Junio C HamanoMay 12, 2015
  16. Junio C HamanoMay 12, 2015
  17. David TurnerMay 12, 2015
  18. Junio C HamanoMay 12, 2015
  19. David TurnerMay 12, 2015
  20. Junio C HamanoMay 14, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.