Re: [PATCH v2 00/14] Sparse checkout

On Sun, 21 Sep 2008, Nguyen Thai Ngoc Duy wrote:

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

quoted

On Sun, 21 Sep 2008, Nguyen Thai Ngoc Duy wrote:

quoted

On 9/21/08, Junio C Hamano [off-list ref] wrote:

[...] 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}. 

By the way it would be nice if gitignore accepted './' as equivalent
to current '/', as this is something I think (from questions here
and on #git) that people expect to work (not reading documentation
carefully enough).  This is something that for example `ls' would use,
or something that `find' returns.

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

Well, this doesn't make sense in a _file_, but makes perfect sense when
invoked from _command line_, as option argument.

But I was thinking more about centralizing pattern matching wrt either
full pathname (with prefix stripped, or not), or basename of a file.
If match check is centralized, then if you enhance pattern language (for
selecting which files to mark no-checkout in sparse checkout for example
by allowing '**' which matches also '/' (if you don't go route of 'tar'
with '--wildcards-match-slash' option)), then it would enhance gitignore
patterns and gitattributes patterns too (well, excluding the fact that
they are delimited differently).
 

quoted

 Second, while unifying the "check the match" part of gitignore,
 gitattribute and sparse checkout would be IMVHO a good idea, [...]

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

And all speedups (well, perhaps not all) would apply to all classes
of matching against patterns as well.
-- 
Jakub Narebski
Poland