Re: What's cooking in git.git (topics)
- From
Andreas Ericsson <ae@op5.se>
- Date
- Nov 2, 2007, 09:39 UTC
- Message-ID
- <472AF042.5080208@op5.se>
- In-Reply-To
- <20071101214257.GB7161@artemis.corp>
Pierre Habouzit wrote:
Show 25 quoted lines
> On Thu, Nov 01, 2007 at 08:27:55PM +0000, Junio C Hamano wrote: >> Geert Bosch <bosch@adacore.com> writes: >> >>> I often type "make clean" as well many "git xyz" commands >>> during development, and so it happens that at times, I type >>> "git clean" by accident. >> Happened to me once. I hate that command. >> >>> So, I propose *not* converting git clean to a C builtin, >>> but instead adding --untracked and --ignored options to >>> git-rm. >> I think what you are trying to do is to deprecate or remove "git >> clean". >> >> I do not know where "git clean" came from. I am suspecting that >> it was to give counterparts to some other SCMs, but do not know >> which ones. Some people wanted to have it --- so you need to >> convince them that it is a bad idea first. Adding an equivalent >> options to "git rm" alone does not solve that issue. > > FWIW I do use git clean a _lot_. I don't mind if it's doable from > another kind of command, but I do use git clean and even git clean -x a > lot, because it achives cleansing my repository faster (and sometimes > faster) than a `make distclean` would do. >
I'm of two minds about this. On the one hand, it's incredibly useful to clear out an imported repository where distlcean doesn't quite distclean. We also use it for our autobuild tools (although that's just us being lazy).
On the other hand, I've been bit by the brain-bug once and done a git clean when I really meant make clean.
Changing it to the wimpy 'rm -i' equivalent would reduce risk substantially while maintaining its usefulness, so +1 to Junio's patch, I guess.
-- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231