Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

On Mon, Aug 25, 2008 at 4:22 PM, Ben Collins [off-list ref] wrote:

David Woodhouse wrote:

quoted

On Sat, 2008-08-23 at 20:33 -0700, Junio C Hamano wrote:

quoted

There is one alternative, and one augmentation:

 (A) We do not do anything.

 (B) In addition to the main transition plan, outside git, prepare an
    optional "git-old-style" package that installs many "git-foo"
    wrappers in $PATH (i.e. /usr/bin).  Each of them exec "git foo".
    People who like the dashed form can keep typing "git-foo", even
    though that will cost them two exec()s.

 (C) Just don't do it. Leave the git-foo commands as they were. They
     weren't actually hurting anyone, and you don't actually _gain_
     anything by removing them. For those occasional nutters who
     _really_ care about the size of /usr/bin, give them the _option_
     of a 'make install' without installing the aliases.

(Oh look, my /usr/bin has 3806 files in it. And except when I
accidentally point the $%#@&! GNOME file dialog box at it, I don't
_care_.)

I'll second that. I've not heard a good argument against the git-foo
commands. If they were going to be deprecated, it should have actually
happened a long time ago.

I personally like to use the git- format in written discussions
regarding git stuff (git-status vs git status), and for man.

I rarely do ls on /usr/bin, so I don't care if there are thousands of
git-whatever files there (thought exec-path somehow feels right), but
I can see how that could be an issue for people with minimal systems
or in different platforms with no hardlinks (win32 on fat32). But in
those cases aliases can be used: git-whatever -> "git whatever".

So I agree, there's no valid reason to remove the git-whatever stuff,
actually for documentation it does makes sense to me.

Best regards.

-- 
Felipe Contreras