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

["Nguyen Thai Ngoc Duy" <pclouds@gmail.com>]

On 9/16/08, Junio C Hamano <gitster@pobox.com> wrote:
> 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.

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 a
set of common prefixes to checkout entries) as a way to reconstruct
narrow spec (simple rules only).
-- 
Duy