Re: [kernel.org users] README and ChangeLog files

Re: [kernel.org users] README and ChangeLog files

[Linus Torvalds]

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

Re: [kernel.org users] README and ChangeLog files

[Petr Baudis]

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

Re: [kernel.org users] README and ChangeLog files

[Michael J Gruber]

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

Re: [kernel.org users] README and ChangeLog files

[Junio C Hamano]

Dominik Brodowski <linux@dominikbrodowski.net> 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.

Re: [kernel.org users] README and ChangeLog files

[Jeff Garzik]

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<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