On Sun, Mar 19, 2017 at 11:15:33AM +0100, Matthieu Moy wrote: > I think the main problem is indeed "stop the users from shooting > themselves in the foot". Many command-line options change the behavior > completely so allowing users to enable them by default means allowing > the users to change Git in such a way that scripts calling it are > broken. > > This also doesn't help when troublshouting an issue as these options are > typically something set once and for all and which you forget about. > This typically leads to discussion in Q&A forums like: > > A: Can you run "git foo"? > B: Here's the result: ... > A: I don't understand, I can't reproduce here. > > just because B has a CLI option enabled by default. > > This is the same reasoning that leads Git to forbid aliasing an existing > command to something else. > > OTOH, we already have almost "enable such or such option by default" > with aliases. People who always run "git am" with "-3" can write > > [alias] > a3 = am -3 > > and just run "git a3". I tend to agree here. At work, we have code that wants git status --porcelain to be empty. If a user added -b to all of their git status calls (to make -s output more helpful), that would break a lot of tooling. It's much better if they create an alias, since that doesn't affect automated tools. I expect developers of things such as fugitive would dislike such a feature as well. I get the impression our existing config file options already make life difficult enough. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature