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

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: Sep 16, 2008, 12:00 UTC
Message-ID: <fcaeb9bf0809160500y4b67c621g45b0c6ddf3745a84@mail.gmail.com>
In-Reply-To: <7vljxtb3tf.fsf@gitster.siamese.dyndns.org>

On 9/16/08, Junio C Hamano <gitster@pobox.com> wrote:

Show 15 quoted lines

> 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.

Show 8 quoted lines

>  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