Re: [PATCH v2 00/14] Sparse checkout

On 9/21/08, Jakub Narebski [off-list ref] wrote:

On Sun, 21 Sep 2008, Nguyen Thai Ngoc Duy wrote:
 > On 9/21/08, Junio C Hamano [off-list ref] wrote:

quoted

quoted

 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