On Mon, Aug 25, 2008 at 4:22 PM, Ben Collins <ben.collins@xxxxxxxxxxxxx> wrote: > David Woodhouse wrote: >> >> On Sat, 2008-08-23 at 20:33 -0700, Junio C Hamano wrote: >>> >>> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
