Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > The same situation happens for "assume unchanged" bit, but I would > expect narrow checkout to be more user-friendly and should notify users > these cases so users will not be confused. On this first step, users > may check by themselves with "git ls-files --overlay",... Could you explain how the earlier --narrow-checkout option introduced in [05/16] interacts with this one? The user has X inside narrow area and Y outside. ls-files reports both X and Y. 'ls-files --narrow-checkout' reports only X. Y is tracked but not really, so 'ls-files --narrow-checkout -o' shouldn't say Y is untracked; there is no cue to tell between X and Y. But with a half of your patch to 'ls-files -t', you already can show these potentially stale (leftover from an ancient checkout un-updated because of narrowness) files. Could a simpler alternative be to do this processing not inside "if (show_deleted/modified)" part of show_files(), but inside "if (show_cached/stage)" part of it? Instead of saying tag_cached unconditionally, if the entry is marked no_checkout, then you would lstat(2) it there and report that the path is "marked not to be checked out but somehow something exists there". By the way, I do not see an easy way to review what paths are marked with no-checkout easily from your command set. It might be worthwhile to add a new option that iterates over the index, finds a set of common prefixes to no-checkout entries and reports that set. -- 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
