[RFC] git clean --local

[RFC] git clean --local

[Cameron Boehmer]

-x and -X are great, but they remove files that are ignored via my
~/.gitignore that I'd rather keep (personal toolchain dotfiles). If
others also would like to see this addressed and we settle on a
specific solution, I'd be happy to submit a patch. Some ideas:

1) add a new flag
-l, --local
    Do not consult git config --global core.excludesFile in
determining what files git ignores. This is useful in conjunction with
-x/-X to preserve user files while removing build artifacts.

2) change the behavior of -x/-X
While it would be inconsistent with git's behavior elsewhere to NOT
consult the global excludesFile, the intent behind -x/-X seems to have
everything to do with the contents of current project's .gitignores,
and nothing to do with the global excludes. However, even if this is
palatable, it's not backwards compatible, and I'm not sure this meets
the threshold of significance for breaking changes.

Of course, I'm open to suggestions.

Thanks to all for their contributions,
Cameron

Re: [RFC] git clean --local

[Junio C Hamano]

Cameron Boehmer <cameron.boehmer@gmail.com> writes:

> 1) add a new flag
> -l, --local
>     Do not consult git config --global core.excludesFile in
> determining what files git ignores. This is useful in conjunction with
> -x/-X to preserve user files while removing build artifacts.

This does not belong to the "clean" command (who says the need to
ignore the global configuration is limited to "clean" and why?), so
"git clean --local" is simply not acceptable.

But it might be useful as an option that affects any "git" command,
e.g. "git --local-config-only clean".  I dunno.

> 2) change the behavior of -x/-X

This won't happen without a long deprecation period.

If you haven't seen and read them, check the recent list archive for
the past few weeks, with keywords "trashable", "precious", etc.

Re: [RFC] git clean --local

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Cameron Boehmer <cameron.boehmer@gmail.com> writes:
>
>> 1) add a new flag
>> -l, --local
>>     Do not consult git config --global core.excludesFile in
>> determining what files git ignores. This is useful in conjunction with
>> -x/-X to preserve user files while removing build artifacts.
> ...
> But it might be useful as an option that affects any "git" command,
> e.g. "git --local-config-only clean".  I dunno.

If you only want to say "there is no global excludes file", perhaps

    $ git -c core.excludesFile=/dev/null clean -x

may be sufficient, so for that particular use case, there is no need
to introduce a new command, I'd think.

In the longer term, however, I think we would want to introduce a
distinction among ignored files---we only support "ignored and
expendable" class, but not "ignored but precious" class.  With the
latter class introduced, it would make sense for "git clean -x/-X"
to notice that a path is ignored but precious and keep it.  If a
dir/foo is ignored, dir/bar is tracked in commit A that is currently
checked out, and there is no dir/ directory in commit B, checking
out commit B would remove dir/foo (because the last tracked file in
the directory goes away and all remaining files in the directory
would be ignored but expendable).  But if we introduced a new
"ignored but precious" class and made dir/foo a member of such a
class, then you will be prevented from checkout out B until you do
something about dir/foo that is now "precious".

Re: [RFC] git clean --local

[Ævar Arnfjörð Bjarmason]

On Sat, Dec 01 2018, Cameron Boehmer wrote:

> 1) add a new flag
> -l, --local
>     Do not consult git config --global core.excludesFile in
> determining what files git ignores. This is useful in conjunction with
> -x/-X to preserve user files while removing build artifacts.

Or perhaps a general flag to ignore configuration would be useful for
such cases, see
https://public-inbox.org/git/87zhtqvm66.fsf@evledraar.gmail.com/

RE: [RFC] git clean --local

[Randall S. Becker]

On December 2, 2018 8:26, Ævar Arnfjörð Bjarmason wrote:
> 
> On Sat, Dec 01 2018, Cameron Boehmer wrote:
> 
> > 1) add a new flag
> > -l, --local
> >     Do not consult git config --global core.excludesFile in
> > determining what files git ignores. This is useful in conjunction with
> > -x/-X to preserve user files while removing build artifacts.
> 
> Or perhaps a general flag to ignore configuration would be useful for such
> cases, see https://public-
> inbox.org/git/87zhtqvm66.fsf@evledraar.gmail.com/

Would something like git clean --exclude=file-pattern work as a compromise notion? Files matching the pattern would not be cleaned regardless of .gitignore or their potential preciousness status long-term. Multiple repetitions of the --exclude option might be supportable. I could see that being somewhat useful in scripting.

Cheers,
Randall

Re: [RFC] git clean --local

[Junio C Hamano]

"Randall S. Becker" <rsbecker@nexbridge.com> writes:


> Would something like git clean --exclude=file-pattern work as a
> compromise notion? Files matching the pattern would not be cleaned
> regardless of .gitignore or their potential preciousness status
> long-term. Multiple repetitions of the --exclude option might be
> supportable. I could see that being somewhat useful in scripting.

I think "git clean" already takes "-e", but I am not sure if it is
meant to do what you wrote above.

If "git clean" takes a pathspec, perhaps you can give a negative
pathspec to exclude whatever you do not want to get cleaned,
something like

	git clean '*.o' ':!precious.o'

to say "presious.o is ignored (hence normally expendable), but I do
not want to clean it with this invocation of 'git clean'"?

Re: [RFC] git clean --local

[Cameron Boehmer]

> > Would something like git clean --exclude=file-pattern work as a
> > compromise notion? Files matching the pattern would not be cleaned
> > regardless of .gitignore or their potential preciousness status
> > long-term. Multiple repetitions of the --exclude option might be
> > supportable. I could see that being somewhat useful in scripting.
>
> I think "git clean" already takes "-e", but I am not sure if it is
> meant to do what you wrote above.

It does already take --exclude=file-pattern, which is like adding
lines to .gitignore. (W/o -x/-X, that would mean DON'T clean them, but
with -x/-X, it means DO clean them.)

>
> If "git clean" takes a pathspec, perhaps you can give a negative
> pathspec to exclude whatever you do not want to get cleaned,
> something like
>
>         git clean '*.o' ':!precious.o'
>

I like this, but I'm also 100% satisfied with Junio's previous suggestion:
    git -c core.excludesFile=/dev/null clean ...

Re: [RFC] git clean --local

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> If "git clean" takes a pathspec, perhaps you can give a negative
> pathspec to exclude whatever you do not want to get cleaned,
> something like
>
> 	git clean '*.o' ':!precious.o'
>
> to say "presious.o is ignored (hence normally expendable), but I do
> not want to clean it with this invocation of 'git clean'"?

Hmph, this leads me to an interesting thought.  With today's code,
these two commands behave in meaningfully different ways when I mark
some paths that match .gitignore patterns with the precious
attribute.

	echo "*.ignored" >>.git/info/exclude
	echo "precious.* precious" >>.git/info/attributes

	: >expendable.ignored 2>precious.ignored

	git clean -n -x
	git clean -n -x ':(exclude,attr:precious)'

I am not suggesting that giving "git clean" a configuration knob
that always append pathspec elements, which would allow users to use
the mechanism to set the above magic pathspec, would be a good
approach.  If we were to follow through this line of thought, an
obvious thing to do is to always unconditonally append the above
magic pathspec internally when running "git clean", which would mean

 * Existing projects and users' repositories will see no behaviour
   change, because they are unaware of the "precious" attribute.

 * People who learn the new feature can start using the "ignored but
   precious" class, without any need for transition period.