Re: [PATCH 16/16] ls-files: add --overlay option

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 15, 2008, 19:35 UTC
Message-ID: <7vljxtb3tf.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <1221397685-27715-17-git-send-email-pclouds@gmail.com>

Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> 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.