Re: [RFC] git clean --local
Junio C Hamano 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.
Re: [RFC] git clean --local
> > 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
"Randall S. Becker" 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
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@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
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@evledraar.gmail.com/
Re: [RFC] git clean --local
Junio C Hamano writes: > Cameron Boehmer 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
Cameron Boehmer 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.
[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
