Re: What's cooking in git.git (topics)

From: Geert Bosch <bosch@adacore.com>
Date: Nov 1, 2007, 19:19 UTC
Message-ID: <916BE4AD-5BD9-48E6-8026-B1AC7387E28D@adacore.com>
In-Reply-To: <alpine.LFD.0.999.0711011129460.3342@woody.linux-foundation.org>

On Nov 1, 2007, at 14:33, Linus Torvalds wrote:

Show 13 quoted lines

> I certainly think this should go in, but it does make one deficiency
> painfully clear: the remaining shell scripts end up having all the old
> flags behaviour.
>
> So while you can combine flags for *most* programs, you still won't
> be able to say things like
>
> 	git clean -qdx
>
> just because that's still a shellscript, and doing any fancy argument
> parsing in shell is just painful.
>
> Is somebody still working on doing the shell->C conversion?

This is by far the most dangerous command we have at this stage, and just too easy to execute by accident. While I now have found out that it is possible to set clean.requireForce to disarm the command, that's the wrong way around. Only experienced users set it, and the mere existence of the config item indicates people do get hosed (and lose data) as a result of the poor semantics.

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.

So, I propose *not* converting git clean to a C builtin, but instead adding --untracked and --ignored options to git-rm.

This fixes two usability issues:
   1. data loss due to command typo
   2. too many git commands

Those who care about "git clean" can setup an alias to make git clean equal to "git rm --untracked"

   -Geert

PS. No patch yet, but I wanted to prevent others from spending
     time on builtin git-clean.