On 9/16/08, Junio C Hamano <gitster@xxxxxxxxx> wrote:> 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.
Right, "ls-files -o" should not list Y as untracked.
> 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".
Yes, makes sense.
> 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.
What is it for? I can only think of it (actually the opposite, find aset of common prefixes to checkout entries) as a way to reconstructnarrow spec (simple rules only).-- Duy��.n��������+%������w��{.n��������n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�m
