vitor.hda@xxxxxxxxx wrote on Fri, 19 Aug 2011 00:43 +0100: > On Fri, Aug 19, 2011 at 12:04 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > This is not a new problem you introduced with this patch, but unless you > > are invoking "git config --bool" in your gitConfig() (I didn't bother to > > check), you will misunderstand different ways to say "Yes", e.g. > > > > [git-p4] > > detectRenames > > detectRenames = on > > detectRenames = yes > > detectRenames = 1 > > > > If you use --bool, you can rely on the values being either true or false, > > and do not have to do the .lower() thing. > > > > Now that I look at this carefully, Tor added the possibility to add arguments to > gitConfig() exactly for that purpose. This is helpful for processing the > detectCopiesHarder option I added. > > For detectRenames and detectCopies it is a bit more complex. I think that if I > use --bool or --bool-or-int then it is possible that certain values will fail to > be processed. Let me give you some examples: > > [git-p4] > detectRenames = true > detectRenames = 80% > detectRenames = 80 > detectRenames = 1% > detectRenames = 1 > > It will be difficult for me to, for example, to understand if a 1 represents 1% > or true. Or am I overcomplicating this? :) I think you have to decide that 1 means 1 in this case. Everything else can mean true. That may suggest that using --bool or --bool-or-int isn't possible in this case. -- Pete -- 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