Mike Hommey <mh@xxxxxxxxxxxx> writes: > On Thu, Nov 01, 2007 at 01:27:55PM -0700, Junio C Hamano wrote: > ... >> 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. > > Well, they could add an alias, then ;) Why do people talk about forcing different behaviour on existing users before proving that the new behaviour is good for everybody, including existing ones? I am personally very much in favor of removing "git clean", but having many people on the list saying loudly that it is a bad command is not good enough justification, as people who are content with the status quo tend to be silent. The steps I think is sensible to transition to that goal would be: - Change clean.requireForce to default to 'true' in the next (or one after) version of git, to make 'clean' even safer. See if anybody complains (I do not expect any). - Implement the same functionarity as a new option to "git rm", which is already in C. - Do "git clean" in C, but sharing the code with "git rm" implementation above. - Discuss deprecation and removal of redundant commands. Ship a version of git with deprecation and future removal notice. Outline how to achieve the same thing as the deprecated command used to do (or give convincing argument why what the deprecated command used to do was a bad thing and do not offer an alternative). - Wait for a while (6 months to 1 year) and then remove them. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
