SZEDER Gábor <szeder@xxxxxxxxxx> writes: > A while ago in a related thread Peff remarked about 'git commit's > '--quiet' and '--verbose' options: > > I think that is a UX mistake, and we would not do > it that way if designing from scratch. But we're stuck with it for > historical reasons (I'd probably name "--verbose" as "--show-diff" or > something if writing it today). > > http://thread.gmane.org/gmane.comp.version-control.git/289027/focus=289069 > > Then I replied: > > However, that doesn't mean that we have to spread this badly chosen > name from options to config variables, does it? I think that if we > are going to define a new config variable today, then it should be > named properly, and it's better not to call it 'commit.verbose', but > 'commit.showDiff' or something. > > http://thread.gmane.org/gmane.comp.version-control.git/289027/focus=289303 > > Any thoughts on this? Before a poorly named config variable enters to > the codebase and we'll have to maintain it "forever"... My thoughts are --show-diff would probably be a UI mistake of a different sort, if you are anticipating that the different kinds of information to be shown in verbose modes would proliferate and that you would want to give the user flexibility to pick and choose to use some while not using some other among them. You would end up having --show-xyzzy --show-frotz --show-nitfol ... options. I am not convinced that we would want such a degree of flexibility in the first place, but even if we did, we'd be better off giving that as "--verbose=diff,xyzzy,frotz...", I would think. And commit.verbose that begins its life as a simple boolean, which can be extended to become bool-or-string if needed, is better than having commit.showDiff, commit.showXyzzy, commit.showFrotz, etc. -- 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