threads / discuss / 15138

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

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

## tl;dr

5 messages between Aug 21, 2008 and Aug 22, 2008.

replies: 4people: 5as markdown or json

Linus Torvalds· Aug 21, 2008, 15:35 UTC · lore

On Wed, 20 Aug 2008, H. Peter Anvin wrote:

Show 5 quoted 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.

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· Aug 21, 2008, 16:01 UTC · re: Linus Torvalds · lore

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· Aug 21, 2008, 16:32 UTC · re: Linus Torvalds · lore

Linus Torvalds venit, vidit, dixit 21.08.2008 17:35:

Show 29 quoted lines

> 
> 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· Aug 22, 2008, 21:13 UTC · lore

Dominik Brodowski <linux@dominikbrodowski.net> writes:

Show 12 quoted lines

> 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· Aug 22, 2008, 23:09 UTC · re: Junio C Hamano · lore

Junio C Hamano wrote:

Show 5 quoted lines

> 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