README and ChangeLog files
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 1219264114.7576.1121.camel@calx
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 57C9024A16AD2D4C97DC78E552063EA309E70713@orsmsx505.amr.corp.intel.com
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · H. Peter Anvin
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
Quoted 4 lines · Linus Torvalds
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
Linus Torvalds venit, vidit, dixit 21.08.2008 17:35:
Quoted 22 lines · H. Peter Anvin
Quoted 4 lines
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.
Quoted 7 lines
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
A message that is not in the archive (sent off-list or not yet received): 1219273792.7576.1146.camel@calx
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 1219294266.7576.1180.camel@calx
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · Dominik Brodowski
Quoted 3 lines · Junio C Hamano
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.
Quoted 7 lines
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.
Quoted 5 lines · Junio C Hamano
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<tab>" 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