Junio C Hamano <gitster@xxxxxxxxx> writes: > 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. -- 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