David Turner <dturner@xxxxxxxxxxxxxxxx> writes: > On Tue, 2015-05-12 at 13:22 -0700, Junio C Hamano wrote: > >> Are there other cases? The only other case I think of is when the >> link resolves cleanly inside the tree, which you already handle. Funny double-inclusion ;-) > While updating the tests, I noticed another two cases: > 1. HEAD:broken-link/file > > I am inclined to describe this as "dangling" as well. (It is not useful > to tell users that "file" is the remaining bit to be resolved, because > due to chains of symlinks, users have no idea what file would be > relative to). I think the filesystem returns ENOENT in the equivalent > case. > > 2. HEAD:link-to-file/file > > This should be "notdir", I think, in that it is a distinct way of > failing that the user might care to know. The filesystem returns ENOTDIR > in the equivalent case. Thanks. > In addition, I would like to have the format for the dangling, loop, and > notdir cases match the missing case. In other words, "HEAD:link > missing", "HEAD:link dangling", etc. Users already need to parse the > missing case, so we might as well make the others match. Interesting to see our opinions differ here, especially because the previous suggestion was coming from "users already need to parse the 'symlink' case, so we might as well make the others match" ;-). Between 'missing' and 'symlink', the latter is richer in information and easier to parse, I would have thought. -- 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