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

From: Stefan Beller <sbeller@google.com>
Date: May 19, 2016, 21:25 UTC
Message-ID: <CAGZ79kYx_pX81bmpyXCvJSVsZW=t3VpBizUPQ90Wz9=HdG42UA@mail.gmail.com>
In-Reply-To: <xmqqshxdhi76.fsf@gitster.mtv.corp.google.com>

On Thu, May 19, 2016 at 2:05 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 32 quoted lines

> Stefan Beller <sbeller@google.com> writes:
>
>> (B) requires some thought though. Here is my vision:
>>
>>     1) Allow pathspecs for sparse checkout.
>>
>>       I wonder if we just add support for that in .git/info-sparse-checkout
>>       or if we add a new file that is for pathspecs only, or we have a config
>>       option whether sparse-checkout follows pathspecs or gitignore patterns
>>
>>     2) Teach `git clone` a new option `--sparse-checkout <pathspec>`
>>       When that option is set the pathspec is written into the new file from
>>       (1) and core.sparsecheckout is set to true
>>
>>     3) Advertise to do a `git clone --sparse-checkout
>> :(attr:default_submodules)`
>>
>> Going this way we would help making submodules not different but integrate more
>> into other concepts of Git. As a downside this would require touching
>> sparse checkout which may be more time consuming than just adding a
>> `git clone --init-submodules-by-label` which stores the labels and only upddates
>> those submodules.
>>
>> Or are there other ideas how to go from here?
>
> My take is to pretend sparse checkout does not exist at all and then
> go from there ;-)  It is a poorly designed and implemented "concept"
> that we do not want to spread around.
>
> You were going to add defaultGroup and teach 'clone' (and other
> commands) about it, and have clone find submodules in that Group,
> right?

Right. But upon finding the new name for clone, I wondered why this has to be submodule specific. The attr pathspecs are also working with any other files. So if you don't use submodules, I think it would be pretty cool to have a

    git clone --sparse-checkout=Documentation/ ...

> Isn't the pathspec magic just another way to introduce
> how you express the "defaultGroup", i.e. not with the "label" thing
> in .gitmodules, but with pathspec elements with attribute magic?

Right. So instead I could do a

    git clone --recursive --restrict-submodules-to=<pathspec> --save-restriction

and then later on

    git submodule update --use-restriction-saved-by-clone

I think we'd not want more than that for some first real tests by some engineers.

However after thinking about this for a while I think it's too submodule centric? The more special sauce we add for submodules the harder they will be to maintain/support as they grow into their own thing down the road.

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.

Why is sparseness considered bad? (I did find only limited resources on the net, those bogs I found are advertising it as the last remainder Git needed to be superior to svn in any discipline; I did not find a lot of negative feedback on it. So I guess usability and confusion?)

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

Thanks, Stefan