Dominik Fischer <d.f.fisc...@web.de> writes: > I strove to create an add.patch configuration option that did the same > as always passing the parameter --patch to git-add. Junio C Hamano > then made me aware that when set, this option would influence and > possibly destroy other commands that internally use git-add. So I > implemented the recursion counter, which is now the first of the two > commits.
This does not solve the problem of scripting. People write scripts, and write git commands in these scripts. "git add" is a very good candidate to appear in scripts, indeed. You can't break people's scripts without a very solid transition plan. And most of the time, safe transition plans are also painful for everyone (remember the push.default change? I'm happy it's done, but that wasn't a lightweight change ...). In this case, it's quite clear to me that any transition plan would be far more painful than the possible benefits. Without breaking backward compatibility, I can already set "alias.p = add --patch" and use "git p" instead of "git add --patch". Even better: that's 2 less keystrokes. A config variable to set an option by default is good when the user wants to set it and forget about it. In this case, you clearly can't "forget about it", as running "git add" and "git add -p" correspond to really different use-cases. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
