[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [PATCH v2 00/14] Sparse checkout
From:       Jakub Narebski <jnareb () gmail ! com>
Date:       2008-09-21 22:14:15
Message-ID: 200809220014.17970.jnareb () gmail ! com
[Download RAW message or body]

On Sun, 21 Sep 2008, Nguyen Thai Ngoc Duy wrote:
> 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:

> [...] 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).
 
>>  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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]