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

[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