Re: git cvsimport and case-insensitive config
- From
Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
- Date
- Mar 31, 2010, 06:54 UTC
- Message-ID
- <y2kcb7bb73a1003302354wea191dd4iced4360b95d31a2a@mail.gmail.com>
- In-Reply-To
- <7vd3yls8pi.fsf@alter.siamese.dyndns.org>
On Wed, Mar 31, 2010 at 1:14 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 17 quoted lines
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
>> (-s likely has a single character, -S more than one. -S is likely to
>> have * or ?, -s not.)
>
> The value given to -S can just be 'tests', or even "\.", as the regexp
> match is not anchored on either side:
>
> if ($opt_S && $fn =~ m/$opt_S/) {
> print "SKIPPING $fn v $rev\n";
> ...
>
> And "-s" would likely be one or more (but not too many) non-alphanumeric
> characters.
>
> But a bigger question is if you can bet on that heuristics, and when the
> heuristics does not work, what you would do.What I wonder is: when would the heuristics not work? Are there git repositories that have a cvsimport configuration with both -s and -S specified? I strongly suspect the answer is NO because such a configuration would not work currently (at least not reliably as the wrong value would be assigned to at least one of the keys.
Show 8 quoted lines
>>> A bigger reason is that, if you have _any_ combination that you cannot >>> reliably guess, you would either need the user to ask for help, or you >>> need to convert by reading the configuration file case-sensitively >>> yourself to come up with a reliable conversion. I opted for the latter. >> >> Would such a configuration work at all? > > What configuration?
One that specifies either of cvsimport.s and cvsimport.S, or any other conflicting key, in a way that the present config reading doesn't get too confused by. I think that for migration it would be sufficient to just follow the value assignments currently done by the code. With a big fat WARNING: notice, possibly.
-- Giuseppe "Oblomov" Bilotta