On Tue, 2015-05-12 at 11:43 -0700, Junio C Hamano wrote: > David Turner <dturner@xxxxxxxxxxxxxxxx> writes: > > >> We need to also say something about the "missing" vs "loop" case, if > >> we choose to leave that part broken. I'd rather see it fixed, but > >> that is not a very strong preference. > > > > Will add an example. > > I do not think we need an example. By "also say", I meant in > addition to "This and that does not currently work", we also need to > say that loops do not work well. In other words, it is enough to > just mention that it is a current limitation (or a bug, whichever we > choose to call) that loops are reported as missing. The version of the patch that we are commenting on contained the text: > + --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 Is that sufficient? Actually, we could simply have a separate output for broken links. Instead of [original path] SP missing, [original path] SP loop. I would probably implement this with a special error return code (SYMLINK_LOOP=-2 instead of the usual -1). Does that seem reasonable to you? -- 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