# Re: [kernel.org users] README and ChangeLog files 5 messages from 2008-08-21 to 2008-08-22. Participants: Linus Torvalds, Petr Baudis, Michael J Gruber, Junio C Hamano, Jeff Garzik. Thread: https://gitlist.dev/t/15138 ## Linus Torvalds, 2008-08-21 15:35 Subject: Re: [kernel.org users] README and ChangeLog files Message-ID: URL: https://gitlist.dev/e/alpine.LFD.1.10.0808210830080.3487%40nehalem.linux-foundation.org In-Reply-To: <48AD03BD.9000909@zytor.com> ``` On Wed, 20 Aug 2008, H. Peter Anvin wrote: > > Personally, I think this grand renaming was a huge step backwards; an attempt > to be bug-compatible with other SCMs. The only people I personally ever saw > complaining about the situation in the first place were people who were > fanbois of some other SCM. Heh. It's true that the push came from people who were used to the "scm xyz" model, but it's also true that git basically made the situation in /usb/bin even worse. You _can_ actually have the "best of both worlds" (if you really do want to continue the "git-xyzzy" usage) by doing PATH=$PATH:$(git --exec-path) although there has been noise about removing the built-in commands entirely even from there. I'm cc'ing the git mailing list just to bring the point up - I'm the one who actually championed removing the "unnecessary" hardlinks, and it seems that nto doing so was the right choice. One of the reasons that the dashed format is being removed is a real technical one, though: git aliases. They never supported the dashed format, since they never were real executables (that's the whole point of an alias, after all). So even with the above path thing, you'll still have to use the spacey version for any aliases you use. Linus ``` ## Petr Baudis, 2008-08-21 16:01 Subject: Re: [kernel.org users] README and ChangeLog files Message-ID: <20080821160113.GM10544@machine.or.cz> URL: https://gitlist.dev/e/20080821160113.GM10544%40machine.or.cz In-Reply-To: ``` On Thu, Aug 21, 2008 at 08:35:52AM -0700, Linus Torvalds wrote: > One of the reasons that the dashed format is being removed is a real > technical one, though: git aliases. They never supported the dashed > format, since they never were real executables (that's the whole point of > an alias, after all). On the other hand, with the dashed form you can easily use shell aliases. Sure, there are differences, like that they are set per-session at most, not per-repository; but if you actually define different aliases with same names in your repositories, that seems like shooting yourself in the foot elaborately most of the time. Petr "Pasky" Baudis ``` ## Michael J Gruber, 2008-08-21 16:32 Subject: Re: [kernel.org users] README and ChangeLog files Message-ID: URL: https://gitlist.dev/e/g8k5b6%2432a%241%40ger.gmane.org In-Reply-To: ``` Linus Torvalds venit, vidit, dixit 21.08.2008 17:35: > > On Wed, 20 Aug 2008, H. Peter Anvin wrote: >> Personally, I think this grand renaming was a huge step backwards; an attempt >> to be bug-compatible with other SCMs. The only people I personally ever saw >> complaining about the situation in the first place were people who were >> fanbois of some other SCM. > > Heh. It's true that the push came from people who were used to the "scm > xyz" model, but it's also true that git basically made the situation in > /usb/bin even worse. > > You _can_ actually have the "best of both worlds" (if you really do want > to continue the "git-xyzzy" usage) by doing > > PATH=$PATH:$(git --exec-path) > > although there has been noise about removing the built-in commands > entirely even from there. I'm cc'ing the git mailing list just to bring > the point up - I'm the one who actually championed removing the > "unnecessary" hardlinks, and it seems that nto doing so was the right > choice. > > One of the reasons that the dashed format is being removed is a real > technical one, though: git aliases. They never supported the dashed > format, since they never were real executables (that's the whole point of > an alias, after all). > > So even with the above path thing, you'll still have to use the spacey > version for any aliases you use. Come to think of it: Maybe commands like "git pull" should, when spitting out warnings, refer to "git help pull" rather than "git-pull(1)" now. I do like it spacey, but the man issue is confusing. It continues with the links in the help/man pages, of course. Michael ``` ## Junio C Hamano, 2008-08-22 21:13 Subject: Re: [kernel.org users] README and ChangeLog files Message-ID: <7vej4g92io.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vej4g92io.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20080822082908.GA29475@isilmar.linta.de> ``` Dominik Brodowski writes: > On Thu, Aug 21, 2008 at 04:20:25PM -0700, Junio C Hamano wrote: >> Yes, and the fact that it is not "git-foo" that was deprecated, but >> running the dashed-form without adjusting PATH was, makes it impractical >> to issue warning messages before the transition actually happened. > > So I can safely ignore the warning in the release notes which states > > | but users are again strongly encouraged to adjust their > | scripts to use "git xyzzy" form, as we will stop installing > | "git-xyzzy" hardlinks for built-in commands in later releases. > > ? No. What the above means is that the deprecation and removal of git-foo for builtins (such as "git commit") are not done in 1.6.0, but it will eventually happen. So your two choices are: (1) stop using dashed form "git-foo" and replace them with "git foo" form everywhere in your script now and won't worry about this anymore; or (2) add this to the beginning of your existing scripts: PATH=$(git --exec-path):$PATH and later do (1) when you have time. But if you choose to do the latter, please do so after promising that you won't complain like this time everybody did, saying "Oh, I knew it was coming but I have postponed doing it for a long time because it continued to work" ;-) [jc: git list cc'ed] Maybe we should try to see how hard it would be to issue warnings when "git-foo" form is used for builtins before we declare that dashed form is deprecated for builtins, and start warning when the deprecation actually happens. As many people on this thread suggested, it would make the transition easier. ``` ## Jeff Garzik, 2008-08-22 23:09 Subject: Re: [kernel.org users] README and ChangeLog files Message-ID: <48AF4740.2030202@garzik.org> URL: https://gitlist.dev/e/48AF4740.2030202%40garzik.org In-Reply-To: <7vej4g92io.fsf@gitster.siamese.dyndns.org> ``` Junio C Hamano wrote: > Maybe we should try to see how hard it would be to issue warnings when > "git-foo" form is used for builtins before we declare that dashed form is > deprecated for builtins, and start warning when the deprecation actually > happens. As many people on this thread suggested, it would make the > transition easier. I would tend to prefer a compatibility package or similar. My fingers have long learned "git-prefix" for several commands. And Fedora puts so much crap in /usr/bin anyway, I don't see it a big deal to have all those names in the directory. Actually, I bet git-foo, git-bar, and git-blah could all link to the same compatibility script, which simply invokes "git $command $args..." That would be nice. Jeff ```