Re: [PATCH v2 00/14] Sparse checkout

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

On 9/21/08, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sun, 21 Sep 2008, Nguyen Thai Ngoc Duy wrote:
>  > On 9/21/08, Junio C Hamano <gitster@pobox.com> wrote:
>
>
> > >  How would that --narrow-match that is not stored anywhere on the
>  > >  filesystem but used only for filtering the output be any more useful than
>  > >  a grep that filters ls-files output in practice?
>  >
>  > Well, it works exactly like 'grep' internally.
>  >
>  > >  I would imagine it would be much more useful if .git/info/attributes can
>  > >  specify "checkout" attribute that is defined like this:
>  > >
>  > >         `checkout`
>  > >         ^^^^^^^^^^
>
> [...]
>
>
>  > >  Then whenever a new path enters the index, you _could_ check with the
>  > >  attribute mechanism to set the CE_NOCHECKOUT flag.  Just like an already
>  > >  tracked path is not ignored even if it matches .gitignore pattern, a path
>  > >  without CE_NOCHECKOUT that is in the index is checked out even if it has
>  > >  checkout attribute Unset.
>  > >
>  > >  Hmm?
>  >
>  > Well I think people would want to save no-checkout rules eventually.
>  > But I don't know how they want to use it. Will the saved rules be hard
>  > restriction, that no files can be checked out outside defined areas?
>  > Will it be to save a couple of keystrokes,   that is, instead of
>  > typing "--reset-sparse=blah" all the time, now just "--reset-sparse"
>  > and default rules will be applied? Your suggestion would be the third,
>  > applying on new files only.
>  >
>  > Anyway I will try to extend attr.c a bit to take input from command
>  > line, then move "sparse patterns" over to use attr.c.
>
>
> First, I think that this was Junio asking for discussion more than
>  for changing the design.

I just tried to see if it was feasible. Checking the source again, I
misunderstood  gitattributes/gitingore's leading '/' notion (in a good
way). Leading '/' means './' and that would be fine for
.git{attributes,ignore}. In sparse patterns, leading '/' means
toplevel directory because you may want to checkout some more from a
subdirectory without moving up to toplevel directory. Now
.git{ignore,attributes} and sparse patterns are incompatible, gaah...

>  Second, while unifying the "check the match" part of gitignore,
>  gitattribute and sparse checkout would be IMVHO a good idea, I'm

It is surely good. Optimization like 68492fc (Speedup scanning for
excluded files.) could be applied to .gitattributes too. Now I know
why I was confused when reading the matching part of
.git{attributes,ignore}.
-- 
Duy