Re: [PATCH] Move all dashed form git commands to libexecdir

[Junio C Hamano <gitster@pobox.com>]

Jan Hudec <bulb@ucw.cz> writes:

> On Tue, Nov 27, 2007 at 16:18:01 +0000, Johannes Schindelin wrote:
>> Hi,
>> 
>> On Tue, 27 Nov 2007, Nguyễn Thái Ngoc Duy wrote:
>> 
>> >  Both configure and make-only ways should work now
>> 
>> I thought your plan was to put the non-porcelain into the libexecdir only?
>
> I had the impression that deprecating the dash notation for /all/ use was
> approved some time ago. Though I don't want to search through the list
> archives this late in the night to check it.

Yes.  Moving the dash-form commands out of end user's PATH was something
distros and users have been allowed to do since forever, and strictly
speaking, using dash form from the command line was already deprecated
at that point.

If your script runs git-foo without first asking "git --exec-path" and
prepending it to the path, your script would not find git-foo if the
installation uses gitexecdir that is not on the usual $PATH, either.

I essentially just said that your patch is unnecessary, but at the same
time, your patch does not go far enough.  As Nico earlier pointed out,
we ship a sample rpm spec, which would also need to be updated.  We do
not ship a sample debian/rules anymore, thank $DEITY ;-)

Also, because we do not remove existing files from the installation
target directory when we do "make install", the commit log message
should carry a big fat warning that says "remove old installation of git
from your $(bindir) when you try this," for people who build from the
source, and we need to repeat the deprecation notice in bold red letters
in the Release Notes for perhaps git 1.6.0.

In case somebody is thinking about 36e5e70e0f40 (Start deprecating
"git-command" in favor of "git command"), that is a somewhat different
issue.  What Linus suggested is not installing git-foo link for built-in
commands _anywhere_ on the filesystem.  Not just "out of user's PATH".
That is not deprecating dash form but removing the support for it.  We
need to give ample time for users to adjust to such a change.