Re: [PATCH v2 00/14] Sparse checkout
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Sep 21, 2008, 22:14 UTC
- Message-ID
- <200809220014.17970.jnareb@gmail.com>
- In-Reply-To
- <fcaeb9bf0809210432x500cf586k877d07b335bf33de@mail.gmail.com>
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).
Show 7 quoted lines
>> 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