On Wed, Mar 16, 2016 at 12:54 AM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: >> As Eric Sunshine mentioned ($gmane.org/288811), it would react >> according to the multiple verbosity level and since its not currently >> defined in `commit` it will react as it is reacting when verbosity >> level is 1. > > I get the feeling that you missed SZEDER's point which was that > git-commit already behaves differently when --verbose is specified > multiple times. (I hadn't gotten around to reviewing that part of the > code yet, so I'm glad that SZEDER saved me the effort.) My bad! I missed SZEDER's point. > The new config variable, which is boolean, doesn't mesh well with > multiple verbosity levels. For instance, with a combination of > commit.verbose=true and a single --verbose, the code will think that > --verbose was given twice and use verbosity level 2, which is not at > all intuitive and would be surprising for the user. So, SZEDER was > asking how this impedance mismatch can be rectified. > > A possibly sane approach would be to make commit.verbose be a > verbosity level rather than boolean, and behave as follows: > > 1. if --verbose is used (one or more), completely ignore commit.verbose. > 2. else, if commit.verbose is set, use it. > 3. else, default behavior. > > I'm not sure if this makes sense, but as a convenience, maybe also > recognize "true" and "false" as aliases for 1 and 0, respectively, for > values of commit.verbose. > > And, of course you'd want to test these behaviors. This seems a good approach to me. I have two ideas of implementing it. First one to introduce a new variable `config_verbose` to store the value read by the config. Till then the value of verbose can be set through command line options. Depending on the situation as you described, it can then make the modification. Another approach would be to swap the places where the configuration file is read and where arguments are parsed. I personally think the first approach as more appropriate as in the latter one, there might be some parts of code which can break. As for the part of alias, I can use the method git_config_bool_or_int() which takes care about aliasing for me. I will also write tests for this behavior. -- 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