Re: What's cooking in git.git (Dec 2010, #01; Sat, 4)

From: Yann Dirson <dirson@bertin.fr>
Date: Dec 6, 2010, 07:29 UTC
Message-ID: <20101206082948.1403cc5a@chalon.bertin.fr>
In-Reply-To: <7v62v8ufyl.fsf@alter.siamese.dyndns.org>

Show 17 quoted lines

>> On Sat, Dec 04, 2010 at 10:30:21PM -0800, Junio C Hamano wrote:
>>> * kb/diff-C-M-synonym (2010-11-29) 1 commit
>>>  - diff: add --detect-copies-harder as a synonym for
>>> --find-copies-harder
>>> 
>>> Will merge to 'next' soon.
>>
>> If we go this way, don't we want to deprecate --find-copies-harder as
>> well ?
>
>Why?
>
>We are being nice to people who did not know --find-copies-harder but
>learned the --detect-renames long name before learning it, which by
>definition is are people because the long names have been there only for
>the last few months; they may expect "detect" to work there.  That is
>the sole purpose of the additional synonym.

But then, why not simply use --find-renames (since --detect-renames has luckily not been released ontl the masses yet), and avoid making similar-usage opts dissimilar and then adding a synonym just to make them similar the other way ?

IOW, we already have tons of options everywhere, let's not just add clutter. We'll end up here with those people used to using --detect-copies-harder willing shell completion; that will just add one more item to the list we get after "--<TAB>", and it will eat precious screen space for pretty much nothing.

Just my 0.02€...

-- 
Yann Dirson - Bertin Technologies