[RFC] git clean --local

-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

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

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.

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.

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

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".

On Sat, Dec 01 2018, Cameron Boehmer wrote:

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/

On December 2, 2018 8:26, Ævar Arnfjörð Bjarmason wrote:

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

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

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'"?

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.)

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

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

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.