From: Alan Braithwaite Date: Fri, 06 Mar 2026 21:50:20 GMT Subject: Re: [PATCH v3] clone: add clone..defaultObjectFilter config Message-ID: <18655b73-0050-4255-aa7a-c0bcb854fc6b@app.fastmail.com> In-Reply-To: > Do we have a way to defeat the configured filter to say "no > filtering, we want everything" from the command line? If not, that > needs to be addressed, if we were to add this configuration. Great point, added a check for the no-filter flag and made that override any defaultObjectFilter setting for the clone. Thanks, - Alan On Fri, Mar 6, 2026, at 11:33, Junio C Hamano wrote: > "brian m. carlson" writes: > >> We've historically not implemented default filtering for clones because >> it makes it hard to reason about the behaviour of the clone command. >> For instance, if I have a script that clones a repository, it almost >> certainly expects a full clone unless it requested something else. >> ... >> We've traditionally placed this kind of customizable configuration into >> `scalar` instead, which is designed to be configurable and set options >> for large repositories that would want to control clone and fetch >> options. > > Hmph, my knee-jerk reaction to the early part of your message was > "oh, but isn't clone a Porcelain (admittedly without corresponding > plumbing) whose defaults and end-user experiences are meant to be > updated from time to time to help users?" but I didn't realize that > we have another class, which is "scalar", these days that we can add > these settings to. I do not have objections to add something to > "scalar", but I personally feel that the configuration for clone is > such a bad thing to have. > > Do we have a way to defeat the configured filter to say "no > filtering, we want everything" from the command line? If not, that > needs to be addressed, if we were to add this configuration. > > Thanks.