Re: [PATCHv8 0/5] pathspec magic extension to search for attributes

From: Duy Nguyen <pclouds@gmail.com>
Date: May 22, 2016, 11:45 UTC
Message-ID: <CACsJy8CpYmp9t01RSeVY_UAw=zPmhGTY1TZ_p2E2zLuu7LpXhA@mail.gmail.com>
In-Reply-To: <CAGZ79kYx_pX81bmpyXCvJSVsZW=t3VpBizUPQ90Wz9=HdG42UA@mail.gmail.com>

On Fri, May 20, 2016 at 4:25 AM, Stefan Beller <sbeller@google.com> wrote:

>> My take is to pretend sparse checkout does not exist at all and then
>> go from there ;-)

Hehe.. shameless plug, narrow checkout [1] should be its great successor where everything is done right (famous last words). Maybe I can convince Stefan to finish that off then I'll finally bring narrow clone!

[1] http://article.gmane.org/gmane.comp.version-control.git/289112

Show 9 quoted lines

> Using these pathspec attrs are a good example for why we would
> want to make it more generic. Imagine a future, where more attributes
> can be codified into pathspecs and this is one of the possibilities:
>
>     git clone --sparse=":(exclude,size>5MB,binary)
>
> which would not checkout files that are large binary files. We could
> also extend the protocol (v2 with the capabilities in client speaks first)
> to transmit such a requirement to the server.

I think you need narrow clone there ;-) It's the first step to have a clone with missing directories. I think then we can extend it further to exclude (large) files.

> Why is sparseness considered bad?

It does not scale well when the worktree gets bigger. It can be slow (but this is just a technical problem I haven't spent time on fixing). And it does not enable narrow clone (not with lots of hacks, I think I did just that in some early iterations).

> If I wanted to just do the submodule only thing, this would be a smaller
> series, I would guess.

No no no. Do more. Start with narrow checkout. I'll help ;-)

-- 
Duy