Re: [PATCH v2 1/4] git-p4: Allow setting rename/copy detection threshold.
- From
- Pete Wyckoff <pw@padd.com>
- Date
- Aug 19, 2011, 11:47 UTC
- Message-ID
- <20110819114719.GB15639@padd.com>
- In-Reply-To
- <CAOpHH-VsoOSOH6ym2exCH=W4NmuKRw+f53HrwB47YD3u-iDe2w@mail.gmail.com>
vitor.hda@gmail.com wrote on Fri, 19 Aug 2011 00:43 +0100:
Show 32 quoted lines
> On Fri, Aug 19, 2011 at 12:04 AM, Junio C Hamano <gitster@pobox.com> 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