[RFD] On deprecating "git-foo" for builtins

[RFD] On deprecating "git-foo" for builtins

[Junio C Hamano]

People seems to have quite strong negative feelings on the removal of
dashed form "git-foo" commands from their $PATH.

We have deprecated the dashed form in early 2006, and announced that 1.6.0
will remove them from $PATH in the 1.5.4 release notes, with instructions
on how to update their scripts before 1.6.0 happens.  Many people knew
about this transition, but they didn't do anything about it.  Since 2005,
git has matured enough that majority of people are using it without
building one themselves, without a chance to even read Release Notes.

The pain was exacerbated partly because we tried to be too nice during the
"deprecation" period, not to annoy people and not to break people's
scripts.

But that niceness backfired.  Many people seem to argue now that we should
have annoyed people by throwing loud deprecation notices to stderr when
they typed "git-foo", and we should have risked breaking their scripts iff
they relied on not seeing anything extra on the stderr.

I am 50% sympathetic to them, while the remainder of me think that they
can say that in retrospect only because they didn't actually got annoyed
with such extra messages and they did not have to fix their scripts before
the actual switch-over happened.  If we did go the "annoy them early"
route, I am sure they would have complained as loudly.

That's all history now anyway.  We should try to do better the next time,
which is much more important, and that is the topic of this message.

Now, we haven't set the timeframe yet, but the original plan, advocated by
Linus and others, was to eventually stop installing "git-foo" form on the
filesystem for builtin commands.  If we were to do this, we should plan
how the deprecation period for this change should look like.  I think the
sequence of events would look like this:

 (1) Declare that the dashed form are deprecated even in scripts that use
     "git --exec-path" the way 1.5.4 release notes suggested (it does not
     make sense to say "deprecated only for builtins", as the distinction
     between builtins and others are implementation details) and will be
     removed in 1.7.0;

 (2) Update git.c (the "git" wrapper) so that when the command is invoked
     in "git-foo" form for a builtin, issue messages to the standard error
     stream about the deprecation.  Also, when the wrapper invokes an
     external "git-foo" command, it exports an environment variable (say,
     "GIT_WRAPPER_IS_RUNNING_YOU");

     Update non-builtin commands and scripts to first check the
     environment variable, and otherwise issue the same deprecation
     message, and then unset the environment variable before continuing.

 (3) At 1.7.0, stop installing the hardlinks to builtin commands.

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.

I personally do not mind seeing dozens of git-foo commands in /usr/bin,
did not have strong opinion on the transition we just did either way, but:

 * Alternative (A) does not logically make much sense.  Now with 1.6.0,
   people are strongly encouraged to use "git foo" form already.

 * Variant (B) feels quite backwards and I think it will have a negative
   effect on our userbase in the longer term. People who train their
   fingers to say "git-foo" on machines with the "git-old-style" package
   will have hard time adjusting to working on machines without it.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Linus Torvalds]

On Sat, 23 Aug 2008, 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.

I actually suspect that (A) is fine.

I suggested removing the "git-xyzzy" hardlinks entirely, but that was just 
because I didn't think anybody wanted them.

But given that with the 1.6.0 model you can always just do

	PATH="PATH:$(git --exec-path)"

in your .bashrc or similar to get the git-xyzzy form, and given that 
clearly some people like using them, there's really no downside to keeping 
them.

I _would_ suggest against putting them in /usr/bin, even as a 
"compatibility plan". Just expose them to people who want them, who can 
really quite easily do the above PATH setting.

		Linus

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Imran M Yousuf]

On Sun, Aug 24, 2008 at 10:23 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Sat, 23 Aug 2008, 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.
>
> I actually suspect that (A) is fine.
>
> I suggested removing the "git-xyzzy" hardlinks entirely, but that was just
> because I didn't think anybody wanted them.
>
> But given that with the 1.6.0 model you can always just do
>
>        PATH="PATH:$(git --exec-path)"
>

If it is simple enough to get the git-abc commands by simply editing
the PATH var then I would have to agree that (A) is the option I would
prefer as well (not that I am as important as Linus though :)). I am
also using the git-abc formats in some of my scripts but I would
rather edit the PATH variable than to have then installed in /usr/bin
(Not to mention that I will be update to 'git abc' as soon as I have
time :)).

> in your .bashrc or similar to get the git-xyzzy form, and given that
> clearly some people like using them, there's really no downside to keeping
> them.
>
> I _would_ suggest against putting them in /usr/bin, even as a
> "compatibility plan". Just expose them to people who want them, who can
> really quite easily do the above PATH setting.
>
>                Linus
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Best regards

-- 
Imran M Yousuf
Email: imran@smartitengineering.com
Blog: http://imyousuf-tech.blogs.smartitengineering.com/
Mobile: +880-1711402557

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Stefan Richter]

Junio C Hamano wrote:
> People seems to have quite strong negative feelings on the removal of
> dashed form "git-foo" commands from their $PATH.

Some of them may appreciate git-completion.bash.  On my box I found it 
named /usr/share/bash-completion/git.
-- 
Stefan Richter
-=====-==--- =--- ==---
http://arcgraph.de/sr/

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[David Woodhouse]

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_.)

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Geert Uytterhoeven]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1541 bytes --]

On Mon, 25 Aug 2008, 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.

Acked-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>

BTW, now we have man pages for deprecated commands that are not in the default
PATH, which are showing examples for deprecated commands that are not in the
default PATH?

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Andi Kleen]

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

(Ca) Only leave the widely used commands in $PATH and remove the ones
which are mostly used by internal scripts only.

-Andi

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Ben Collins]

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.

-- BenC, late to the discussion as usual

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Felipe Contreras]

On Mon, Aug 25, 2008 at 4:22 PM, Ben Collins <ben.collins@canonical.com> 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

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Johannes Schindelin]

Hi,

On Mon, 25 Aug 2008, 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.

Umm.  What exactly makes you feel you should ignore the discussions we had 
around the issues on the git and msysgit mailing list?

Ciao,
Dscho

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Mon, 25 Aug 2008, 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.
>
> Umm.  What exactly makes you feel you should ignore the discussions we had 
> around the issues on the git and msysgit mailing list?

Well, this was partly my fault, as I did not make it clear in this part
that beating the horse that has been dead for two years is not a
productive way to spend out time.  I however did, in the part David did
not quote, try to make it clear:

  That's all history now anyway.  We should try to do better the next time,
  which is much more important, and that is the topic of this message.

  Now, we haven't set the timeframe yet, but the original plan, advocated by
  Linus and others, was to eventually stop installing "git-foo" form on the
  filesystem for builtin commands.  If we were to do this, we should plan
  how the deprecation period for this change should look like.  I think the
  sequence of events would look like this:

that we are now talking about what we can do better from here going
forward, but these paragraphs were separated from the quoted part that
describes what kind of *variations* are possible in addition to the "the
sequence of events would look like this:" list, and allowed David to make
an out of context quoting that made a comment on an offtopic tangent look
as if it were one of the valid alternatives.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[A Large Angry SCM]

David Woodhouse wrote:
> 
>   (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.

Acked-by: A Large Angry SCM <gitzilla@gmail.com>

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[A Large Angry SCM]

Andi Kleen wrote:
>>   (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.
> 
> (Ca) Only leave the widely used commands in $PATH and remove the ones
> which are mostly used by internal scripts only.

Please define what you mean by "widely used". I define it as "any git 
command I care use".

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jean Delvare]

On Mon, 25 Aug 2008 22:58:37 -0400, A Large Angry SCM wrote:
> David Woodhouse wrote:
> > 
> >   (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.
> 
> Acked-by: A Large Angry SCM <gitzilla@gmail.com>

Such statements from anonymous people have zero value, sorry.

-- 
Jean Delvare

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[A Large Angry SCM]

Jean Delvare wrote:
> On Mon, 25 Aug 2008 22:58:37 -0400, A Large Angry SCM wrote:
>> David Woodhouse wrote:
>>>   (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.
>> Acked-by: A Large Angry SCM <gitzilla@gmail.com>
> 
> Such statements from anonymous people have zero value, sorry.
> 

Do some research; I haven't been anonymous since 2005.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Stefan Richter]

A Large Angry SCM wrote:
> Jean Delvare wrote:
>> On Mon, 25 Aug 2008 22:58:37 -0400, A Large Angry SCM wrote:
>>> David Woodhouse wrote:
>>>>   (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.
>>> Acked-by: A Large Angry SCM <gitzilla@gmail.com>
[...]
> Do some research; [...]

...the plan to move git-foo out of /usr/bin has been discussed and 
wrapped up quite a while ago (am I confident to say without being 
subscriber of git@vger.k'org myself).

Instead of unhelpful complaints after the fact, you could try which of 
the many available alternatives work for you:  Extended PATH, shell 
aliases, command line completion setup, links in ~/bin, or so many other 
possibilities of varying degree of sophistication.  If none of these fix 
whatever issues you experience, there is surely opportunity to discuss 
details on the git list.
-- 
Stefan Richter
-=====-==--- =--- ==-=-
http://arcgraph.de/sr/

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[David Woodhouse]

On Mon, 2008-08-25 at 16:41 -0700, Junio C Hamano wrote:
> Well, this was partly my fault, as I did not make it clear in this part
> that beating the horse that has been dead for two years is not a
> productive way to spend out time.  I however did, in the part David did
> not quote, try to make it clear:

Do you have a reference to the previous discussion? In particular, any
part of it where any _real_ benefits of breaking compatibility are
given.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Shawn O. Pearce]

A Large Angry SCM <gitzilla@gmail.com> wrote:
> Jean Delvare wrote:
>>>
>>> Acked-by: A Large Angry SCM <gitzilla@gmail.com>
>>
>> Such statements from anonymous people have zero value, sorry.
>>
>
> Do some research; I haven't been anonymous since 2005.

At which point one has to ask himself, "self, why I am still hiding
behind an anonymous name?"

-- 
Shawn.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jeff King]

On Tue, Aug 26, 2008 at 09:17:01AM +0200, Jean Delvare wrote:

> > Acked-by: A Large Angry SCM <gitzilla@gmail.com>
> 
> Such statements from anonymous people have zero value, sorry.

I think it depends on how you define "anonymous". I don't know
gitzilla's legal name, and nor do I care. But I have seen the reputation
he or she has established through postings on the git list over the past
few years, and that gives the statement non-zero value.

And I don't know who _you_ are, even though you are presumably using
your real name (probably because this message is cross-posted, and you
have some reputation on users@kernel.org, with which I am not familiar).

-Peff

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jeff King]

On Mon, Aug 25, 2008 at 04:41:57PM -0700, Junio C Hamano wrote:

> > Umm.  What exactly makes you feel you should ignore the discussions we had 
> > around the issues on the git and msysgit mailing list?
> 
> Well, this was partly my fault, as I did not make it clear in this part
> that beating the horse that has been dead for two years is not a
> productive way to spend out time.  I however did, in the part David did
> not quote, try to make it clear:
> 
>   That's all history now anyway.  We should try to do better the next time,
>   which is much more important, and that is the topic of this message.

I don't want to stir up this discussion too much; I am sure you have
many more important things to be working on. But I did want to make one
observation.

One side of the argument, I see a lot of "I would prefer it this way."
And on the other side I see a lot of "this discussion is already
history" and "but I do not care personally that much."

It makes me wonder why nobody has said "no, really, I prefer it without
the programs in /bin." Are they simply confident that the decision has
been made, and don't feel the need to say something?

I am just concerned that we are following a path that is not the best
one because "it was decided" already, when perhaps:

  - the reasons for making that decision may have changed

  - the people interested in opposing that decision didn't speak up at
    the time, either because they weren't git users then, weren't as
    active in the mailing list, changed their minds, or were simply too
    lazy to read the release notes

Again, I don't want to waste time (especially yours, Junio) with a
discussion that is fruitless. But I also don't like to see "no, you are
not allowed to bring fresh arguments to this decision". That precludes
the possibility that the decision was wrong.

Maybe the people who want to keep git-* can discuss amongst themselves
(on the list, but the rest of us can ignore it) and present a concise
argument why circumstances around this decision may have changed.

-Peff

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Kristian Høgsberg]

On Tue, 2008-08-26 at 10:57 -0400, Jeff King wrote:
> On Mon, Aug 25, 2008 at 04:41:57PM -0700, Junio C Hamano wrote:
> 
> > > Umm.  What exactly makes you feel you should ignore the discussions we had 
> > > around the issues on the git and msysgit mailing list?
> > 
> > Well, this was partly my fault, as I did not make it clear in this part
> > that beating the horse that has been dead for two years is not a
> > productive way to spend out time.  I however did, in the part David did
> > not quote, try to make it clear:
> > 
> >   That's all history now anyway.  We should try to do better the next time,
> >   which is much more important, and that is the topic of this message.
> 
> I don't want to stir up this discussion too much; I am sure you have
> many more important things to be working on. But I did want to make one
> observation.
> 
> One side of the argument, I see a lot of "I would prefer it this way."
> And on the other side I see a lot of "this discussion is already
> history" and "but I do not care personally that much."
> 
> It makes me wonder why nobody has said "no, really, I prefer it without
> the programs in /bin." Are they simply confident that the decision has
> been made, and don't feel the need to say something?

It's pretty normal to see opponents of a decision like this complain
loudly when it lands on their system, whereas the silent majority in
favour will be happy to see the change finally implemented but reluctant
to stir up the discussion again.

I don't think new arguments are brought to the discussion, just new
people, who are temporarily inconvened by a change towards sanity.

Kristian

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[David Woodhouse]

On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote:
> It's pretty normal to see opponents of a decision like this complain
> loudly when it lands on their system, whereas the silent majority in
> favour will be happy to see the change finally implemented but reluctant
> to stir up the discussion again.
> 
> I don't think new arguments are brought to the discussion, just new
> people, who are temporarily inconvened by a change towards sanity.

Nice emotive response, especially the subtle but unsubstantiated 'silent
majority in favour' bit -- but you forgot the part where you were
supposed to actually point out a tangible benefit which is achieved by
breaking compatibility like this.

And no, reducing the size of /usr/bin by a tiny fraction isn't really a
worthwhile benefit -- in reality, the 'silent majority' really couldn't
give a monkey's left testicle about that, and breakage caused by the
gratuitous change _far_ outweighs any minuscule improvement.

It's particularly silly because we could have just made these aliases
optional but present by default, so those few nutters who _really_ spend
their days worrying about such stuff can do without them.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Matthias Kestenholz]

On Tue, Aug 26, 2008 at 5:59 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote:
>> It's pretty normal to see opponents of a decision like this complain
>> loudly when it lands on their system, whereas the silent majority in
>> favour will be happy to see the change finally implemented but reluctant
>> to stir up the discussion again.
>>
>> I don't think new arguments are brought to the discussion, just new
>> people, who are temporarily inconvened by a change towards sanity.
>
> Nice emotive response, especially the subtle but unsubstantiated 'silent
> majority in favour' bit -- but you forgot the part where you were
> supposed to actually point out a tangible benefit which is achieved by
> breaking compatibility like this.
>
> And no, reducing the size of /usr/bin by a tiny fraction isn't really a
> worthwhile benefit -- in reality, the 'silent majority' really couldn't
> give a monkey's left testicle about that, and breakage caused by the
> gratuitous change _far_ outweighs any minuscule improvement.
>

Correct, but there is a benefit. Imagine a new user:

git-<tab><tab> ... what? 140-something commands? I'll better start looking
for alternatives _right now_!

Having a cluttered namespace is never a good thing. It means that it's
less obvious which commands you are supposed to use etc.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Kristian Høgsberg]

On Tue, 2008-08-26 at 16:59 +0100, David Woodhouse wrote:
> On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote:
> > It's pretty normal to see opponents of a decision like this complain
> > loudly when it lands on their system, whereas the silent majority in
> > favour will be happy to see the change finally implemented but reluctant
> > to stir up the discussion again.
> > 
> > I don't think new arguments are brought to the discussion, just new
> > people, who are temporarily inconvened by a change towards sanity.
> 
> Nice emotive response, especially the subtle but unsubstantiated 'silent
> majority in favour' bit -- but you forgot the part where you were
> supposed to actually point out a tangible benefit which is achieved by
> breaking compatibility like this.

Oh get off your high horse, this entire thread is pretty much all
bullshit and emotions.  Not every arbitrary decision deserves to be set
in stone and be defended under the banner of backwards compatibility.

Kristian

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jean Delvare]

On Tue, 26 Aug 2008 16:59:58 +0100, David Woodhouse wrote:
> On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote:
> > It's pretty normal to see opponents of a decision like this complain
> > loudly when it lands on their system, whereas the silent majority in
> > favour will be happy to see the change finally implemented but reluctant
> > to stir up the discussion again.
> > 
> > I don't think new arguments are brought to the discussion, just new
> > people, who are temporarily inconvened by a change towards sanity.
> 
> Nice emotive response, especially the subtle but unsubstantiated 'silent
> majority in favour' bit -- but you forgot the part where you were
> supposed to actually point out a tangible benefit which is achieved by
> breaking compatibility like this.
> 
> And no, reducing the size of /usr/bin by a tiny fraction isn't really a
> worthwhile benefit -- in reality, the 'silent majority' really couldn't
> give a monkey's left testicle about that, and breakage caused by the
> gratuitous change _far_ outweighs any minuscule improvement.

Reducing /usr/bin in size was totally worthwhile. Maybe not to you, but
to the silent majority I am a proud member of, it was. (I'm not saying
that the path that was taken to get there was optimal, just that the
goal was sound.)

I just can't think of any other tool which installs over 100 binaries
(or scripts, that's the same) in /usr/bin. Can you? This is simply
insane. If all tools did what git did, you'd have maybe 100,000 files
in /usr/bin (that is, if your filesystem supports that) and your system
would be pretty slow. So I'm very glad to see git come back to reason.
If nothing else, just so that other tool authors don't think it's the
right way to do it.

> It's particularly silly because we could have just made these aliases
> optional but present by default, so those few nutters who _really_ spend
> their days worrying about such stuff can do without them.


-- 
Jean Delvare

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Petr Baudis]

On Tue, Aug 26, 2008 at 06:04:00PM +0200, Matthias Kestenholz wrote:
> Correct, but there is a benefit. Imagine a new user:
> 
> git-<tab><tab> ... what? 140-something commands? I'll better start looking
> for alternatives _right now_!

Actually, this is the only realistic argument I can remember at all.
Are there any others? I couldn't come up with any - but I didn't do much
history digging: others seem to be equally in dark, though.

(And I'm not saying this one is not important; it's apparently a
significant "P.R." issue. But is just this _the_ official rationale?)

> Having a cluttered namespace is never a good thing. It means that it's
> less obvious which commands you are supposed to use etc.

This is not much of a valid argument; you could install the same set of
commands to /usr/bin that you are offering in the bash autocompletion.
(With the catch that this might break peoples scripts in a subtler way
than just removing all of them.)

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Andi Kleen]

On Tue, Aug 26, 2008 at 06:25:13PM +0200, Petr Baudis wrote:
> On Tue, Aug 26, 2008 at 06:04:00PM +0200, Matthias Kestenholz wrote:
> > Correct, but there is a benefit. Imagine a new user:
> > 
> > git-<tab><tab> ... what? 140-something commands? I'll better start looking
> > for alternatives _right now_!
> 
> Actually, this is the only realistic argument I can remember at all.

It's not very convincing, because the bash completions script file for git 
is installed by default[1] which completes both forms, so the new user will 
experience instead:

git<space><tab><tab>.... what? 140-something commands? etc.etc.

Someone didn't think this through?

I won't disagree that the 140 commands thing is a problem -- I remember
thinking the same thoughts and I am still scared occasionally by
the multitude of commands. But that doesn't seem to be the solution.

-Andi

[1] At least it's in my openSUSE build service git-core rpm by default.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Takashi Iwai]

At Tue, 26 Aug 2008 18:23:49 +0200,
Jean Delvare wrote:
> 
> On Tue, 26 Aug 2008 16:59:58 +0100, David Woodhouse wrote:
> > On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote:
> > > It's pretty normal to see opponents of a decision like this complain
> > > loudly when it lands on their system, whereas the silent majority in
> > > favour will be happy to see the change finally implemented but reluctant
> > > to stir up the discussion again.
> > > 
> > > I don't think new arguments are brought to the discussion, just new
> > > people, who are temporarily inconvened by a change towards sanity.
> > 
> > Nice emotive response, especially the subtle but unsubstantiated 'silent
> > majority in favour' bit -- but you forgot the part where you were
> > supposed to actually point out a tangible benefit which is achieved by
> > breaking compatibility like this.
> > 
> > And no, reducing the size of /usr/bin by a tiny fraction isn't really a
> > worthwhile benefit -- in reality, the 'silent majority' really couldn't
> > give a monkey's left testicle about that, and breakage caused by the
> > gratuitous change _far_ outweighs any minuscule improvement.
> 
> Reducing /usr/bin in size was totally worthwhile. Maybe not to you, but
> to the silent majority I am a proud member of, it was. (I'm not saying
> that the path that was taken to get there was optimal, just that the
> goal was sound.)
> 
> I just can't think of any other tool which installs over 100 binaries
> (or scripts, that's the same) in /usr/bin. Can you?

netpbm has almost 300 in /usr/bin.


Takashi

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Linus Torvalds]

On Tue, 26 Aug 2008, David Woodhouse wrote:
> 
> Nice emotive response, especially the subtle but unsubstantiated 'silent
> majority in favour' bit -- but you forgot the part where you were
> supposed to actually point out a tangible benefit which is achieved by
> breaking compatibility like this.

Umm. The 'git-xyzzy' thing has been one of the #1 complaints since pretty 
much day#1. The number of people complaining about it going away has 
literally been _much_ smaller than the people who complained about it 
being there.

Also, like it or not, it's done. So the argument about "compatibility" is 
TOTAL AND UTTER BULLSHIT. There is no compatibility, because we already 
released a major version without them.

So live with it, and just add the 

	PATH="$PATH:$(git --exec-path)"

as a "compatibility layer" to your own setup already. There is no 
downside, and I think there _is_ a big upside, and no, it's not just about 
"/usr/bin" being smaller.

In case you wonder, the upside is:

 - new people don't even learn the mistakes

 - the people who _did_ complain are happier

 - this model allows a per-user-preference model even on the same machine 
   (ie even on something like master.kernel.org, everybody can choose 
   _individually_ whether they want to see 'git-xyzzy' or not!)

and there really is zero downside apart from the _trivial_ downside of you 
just having to add a single PATH thing to your .bashrc or something.

			Linus

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jeff King]

On Tue, Aug 26, 2008 at 06:45:26PM +0200, Andi Kleen wrote:

> It's not very convincing, because the bash completions script file for git 
> is installed by default[1] which completes both forms, so the new user will 
> experience instead:
> 
> git<space><tab><tab>.... what? 140-something commands? etc.etc.

The bash completion has the luxury of not mentioning some commands if
they are likely to be confusing (i.e., very low-level plumbing).

That being said, it still produces 70-something commands.

-Peff

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Linus Torvalds]

On Tue, 26 Aug 2008, Andi Kleen wrote:
> 
> It's not very convincing, because the bash completions script file for git 
> is installed by default[1] which completes both forms, so the new user will 
> experience instead:
> 
> git<space><tab><tab>.... what? 140-something commands? etc.etc.

No. 

Your argument makes no sense.

When you do

	ls<space><tab><tab>

and it says

	Display all 122 possibilities? (y or n)

(yeah, my home directory is a mess) do you really think "What? 
120-something commands? etc etc".

Hell no, you don't.

There's a big difference between having the space and not having it, and 
anybody who argues otherwise is being dishonest.

		Linus

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jeff King]

On Tue, Aug 26, 2008 at 06:25:13PM +0200, Petr Baudis wrote:

> > git-<tab><tab> ... what? 140-something commands? I'll better start looking
> > for alternatives _right now_!
> 
> Actually, this is the only realistic argument I can remember at all.
> Are there any others? I couldn't come up with any - but I didn't do much
> history digging: others seem to be equally in dark, though.

The three reasons I can recall are:

  - too many commands on completion

  - confusion between "git-*" and "git *" equivalence, and inability to
    perform some operations with "git-*" (like git --no-pager).

  - I might be wrong, but I think there was discussion of a
    hardlink-challenged platform where we wasted space by copying the
    'git' binary. Taking git-* out of /usr/bin is the first step to
    removing the hardlinks entirely.

-Peff

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Petr Baudis]

On Tue, Aug 26, 2008 at 06:45:26PM +0200, Andi Kleen wrote:
> On Tue, Aug 26, 2008 at 06:25:13PM +0200, Petr Baudis wrote:
> > On Tue, Aug 26, 2008 at 06:04:00PM +0200, Matthias Kestenholz wrote:
> > > Correct, but there is a benefit. Imagine a new user:
> > > 
> > > git-<tab><tab> ... what? 140-something commands? I'll better start looking
> > > for alternatives _right now_!
> > 
> > Actually, this is the only realistic argument I can remember at all.
> 
> It's not very convincing, because the bash completions script file for git 
> is installed by default[1] which completes both forms, so the new user will 
> experience instead:
> 
> git<space><tab><tab>.... what? 140-something commands? etc.etc.

No, the point of course is that you should get much less.

It offers 66 commands to me here, though it's still way too many - some
of them are clearly plumbing: count-objects, ls-tree, checkout-index?
Someone should submit a patch! ;-) (After eliminating these, this comes
down to 56 commands - which is still a lot, but the numbers are getting
somewhat sane already.)

				Petr "Pasky" Baudis

[PATCH] bash completion: Hide more plumbing commands

[Petr Baudis]

git <tab><tab> still shows way too many commands, some of them
are clearly plumbing. This patch hides the plumbing commands
liberally (that is, in special cases, users still might want to
call one of the hidden commands, a *normal* workflow should never
involve these, though - and if it does, we have a UI problem anyway).

Signed-off-by: Petr Baudis <pasky@suse.cz>
---

 contrib/completion/git-completion.bash |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 89858c2..773d64b 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -386,7 +386,9 @@ __git_porcelain_commands ()
 		cat-file)         : plumbing;;
 		check-attr)       : plumbing;;
 		check-ref-format) : plumbing;;
+		checkout-index)   : plumbing;;
 		commit-tree)      : plumbing;;
+		count-objects)    : plumbing;;
 		cvsexportcommit)  : export;;
 		cvsimport)        : import;;
 		cvsserver)        : daemon;;
@@ -395,6 +397,7 @@ __git_porcelain_commands ()
 		diff-index)       : plumbing;;
 		diff-tree)        : plumbing;;
 		fast-import)      : import;;
+		fast-export)      : export;;
 		fsck-objects)     : plumbing;;
 		fetch-pack)       : plumbing;;
 		fmt-merge-msg)    : plumbing;;
@@ -404,6 +407,10 @@ __git_porcelain_commands ()
 		index-pack)       : plumbing;;
 		init-db)          : deprecated;;
 		local-fetch)      : plumbing;;
+		lost-found)       : deprecated;;
+		ls-files)         : plumbing;;
+		ls-remote)        : plumbing;;
+		ls-tree)          : plumbing;;
 		mailinfo)         : plumbing;;
 		mailsplit)        : plumbing;;
 		merge-*)          : plumbing;;
@@ -428,6 +435,7 @@ __git_porcelain_commands ()
 		runstatus)        : plumbing;;
 		sh-setup)         : internal;;
 		shell)            : daemon;;
+		show-ref)         : plumbing;;
 		send-pack)        : plumbing;;
 		show-index)       : plumbing;;
 		ssh-*)            : transport;;
@@ -442,6 +450,8 @@ __git_porcelain_commands ()
 		upload-archive)   : plumbing;;
 		upload-pack)      : plumbing;;
 		write-tree)       : plumbing;;
+		var)              : plumbing;;
+		verify-pack)      : plumbing;;
 		verify-tag)       : plumbing;;
 		*) echo $i;;
 		esac

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Shawn O. Pearce]

Petr Baudis <pasky@suse.cz> wrote:
> On Tue, Aug 26, 2008 at 06:45:26PM +0200, Andi Kleen wrote:
> > 
> > It's not very convincing, because the bash completions script file for git 
> > is installed by default[1] which completes both forms, so the new user will 
> > experience instead:
> > 
> > git<space><tab><tab>.... what? 140-something commands? etc.etc.
> 
> No, the point of course is that you should get much less.
> 
> It offers 66 commands to me here, though it's still way too many - some
> of them are clearly plumbing: count-objects, ls-tree, checkout-index?
> Someone should submit a patch! ;-) (After eliminating these, this comes
> down to 56 commands - which is still a lot, but the numbers are getting
> somewhat sane already.)

I'm the reason why count-objects, ls-tree and checkout-index are
still offered by the bash completion.  And sitting here reading your
email I realized its been _months_ since I last called checkout-index
by hand.  I still run count-objects and ls-tree very so often, but the
average user probably doesn't use ls-tree.

So yea, these probably should be removed from the completion list.
But I can make a weak argument for keeping count-objects.

-- 
Shawn.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jeff King]

On Tue, Aug 26, 2008 at 10:12:55AM -0700, Shawn O. Pearce wrote:

> I'm the reason why count-objects, ls-tree and checkout-index are
> still offered by the bash completion.  And sitting here reading your
> email I realized its been _months_ since I last called checkout-index
> by hand.  I still run count-objects and ls-tree very so often, but the
> average user probably doesn't use ls-tree.
> 
> So yea, these probably should be removed from the completion list.
> But I can make a weak argument for keeping count-objects.

I think this message shows the conflict in setting up such a list. We
want the command set to be as tiny as possible to help new users find
their way. But we want the command set to be useful to git power users.

I wonder if there should be multiple sets of commands for completion,
with a minimal set enabled by default, and a "power user" set that
exposes extra commands. I dunno. Maybe that is overengineering. I don't
even use the bash completion at all.

-Peff

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jean Delvare]

On Tue, 26 Aug 2008 18:50:25 +0200, Takashi Iwai wrote:
> At Tue, 26 Aug 2008 18:23:49 +0200,
> Jean Delvare wrote:
> > 
> > On Tue, 26 Aug 2008 16:59:58 +0100, David Woodhouse wrote:
> > > On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote:
> > > > It's pretty normal to see opponents of a decision like this complain
> > > > loudly when it lands on their system, whereas the silent majority in
> > > > favour will be happy to see the change finally implemented but reluctant
> > > > to stir up the discussion again.
> > > > 
> > > > I don't think new arguments are brought to the discussion, just new
> > > > people, who are temporarily inconvened by a change towards sanity.
> > > 
> > > Nice emotive response, especially the subtle but unsubstantiated 'silent
> > > majority in favour' bit -- but you forgot the part where you were
> > > supposed to actually point out a tangible benefit which is achieved by
> > > breaking compatibility like this.
> > > 
> > > And no, reducing the size of /usr/bin by a tiny fraction isn't really a
> > > worthwhile benefit -- in reality, the 'silent majority' really couldn't
> > > give a monkey's left testicle about that, and breakage caused by the
> > > gratuitous change _far_ outweighs any minuscule improvement.
> > 
> > Reducing /usr/bin in size was totally worthwhile. Maybe not to you, but
> > to the silent majority I am a proud member of, it was. (I'm not saying
> > that the path that was taken to get there was optimal, just that the
> > goal was sound.)
> > 
> > I just can't think of any other tool which installs over 100 binaries
> > (or scripts, that's the same) in /usr/bin. Can you?
> 
> netpbm has almost 300 in /usr/bin.

Ouch. (I guess I shouldn't have asked.)

Does netpbm do anything convert (ImageMagick) doesn't? I'd be happy to
get rid of netpbm.

(Sorry for getting off-topic.)

-- 
Jean Delvare

Re: [PATCH] bash completion: Hide more plumbing commands

[Shawn O. Pearce]

Petr Baudis <pasky@suse.cz> wrote:
> git <tab><tab> still shows way too many commands, some of them
> are clearly plumbing. This patch hides the plumbing commands
> liberally (that is, in special cases, users still might want to
> call one of the hidden commands, a *normal* workflow should never
> involve these, though - and if it does, we have a UI problem anyway).
> 
> Signed-off-by: Petr Baudis <pasky@suse.cz>

Acked-by: Shawn O. Pearce <spearce@spearce.org>

Though I use git ls-remote at least once every other day to see
what branches are available on my egit/spearce.git fork.  Its ok,
I guess I can type a few extra characters...

> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 89858c2..773d64b 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -386,7 +386,9 @@ __git_porcelain_commands ()
>  		cat-file)         : plumbing;;
>  		check-attr)       : plumbing;;
>  		check-ref-format) : plumbing;;
> +		checkout-index)   : plumbing;;
>  		commit-tree)      : plumbing;;
> +		count-objects)    : plumbing;;
>  		cvsexportcommit)  : export;;
>  		cvsimport)        : import;;
>  		cvsserver)        : daemon;;
> @@ -395,6 +397,7 @@ __git_porcelain_commands ()
>  		diff-index)       : plumbing;;
>  		diff-tree)        : plumbing;;
>  		fast-import)      : import;;
> +		fast-export)      : export;;
>  		fsck-objects)     : plumbing;;
>  		fetch-pack)       : plumbing;;
>  		fmt-merge-msg)    : plumbing;;
> @@ -404,6 +407,10 @@ __git_porcelain_commands ()
>  		index-pack)       : plumbing;;
>  		init-db)          : deprecated;;
>  		local-fetch)      : plumbing;;
> +		lost-found)       : deprecated;;
> +		ls-files)         : plumbing;;
> +		ls-remote)        : plumbing;;
> +		ls-tree)          : plumbing;;
>  		mailinfo)         : plumbing;;
>  		mailsplit)        : plumbing;;
>  		merge-*)          : plumbing;;
> @@ -428,6 +435,7 @@ __git_porcelain_commands ()
>  		runstatus)        : plumbing;;
>  		sh-setup)         : internal;;
>  		shell)            : daemon;;
> +		show-ref)         : plumbing;;
>  		send-pack)        : plumbing;;
>  		show-index)       : plumbing;;
>  		ssh-*)            : transport;;
> @@ -442,6 +450,8 @@ __git_porcelain_commands ()
>  		upload-archive)   : plumbing;;
>  		upload-pack)      : plumbing;;
>  		write-tree)       : plumbing;;
> +		var)              : plumbing;;
> +		verify-pack)      : plumbing;;
>  		verify-tag)       : plumbing;;
>  		*) echo $i;;
>  		esac

-- 
Shawn.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Andi Kleen]

> When you do
> 
> 	ls<space><tab><tab>

Actually do ls --<tab><tab> and you can well be scared too. 
Perhaps it's not quite git class yet, but it's working on it.
I could imagine some Unix newbie be scared about that.

["Quick: mention the two characters not used as ls short options yet"]

> 
> and it says
> 
> 	Display all 122 possibilities? (y or n)
> 
> (yeah, my home directory is a mess)

It's quite tidy in fact :)

% ls <tab><tab>
Display all 584 possibilities? (y or n)

> 120-something commands? etc etc".

I was assuming someone thinking about using git. At some point
they will do the git<space><tab><tab> thing and be scared away.

Ok maybe it's not the first action, but it's likely in the first 10 
minutes; more or less once they discover that git has sub commands.

Anyways the real solution to that is either having less commands
or hiding the internal ones better. I think both would be fine,
but once that is done and there's a slimmed down non scary list,
there's no reason to not put the remaining non internal ones back 
into $PATH isn't it?

-Andi

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Bruce Stephens]

Linus Torvalds <torvalds@linux-foundation.org> writes:

[...]

> In case you wonder, the upside is:
>
>  - new people don't even learn the mistakes
>
>  - the people who _did_ complain are happier
>
>  - this model allows a per-user-preference model even on the same machine 
>    (ie even on something like master.kernel.org, everybody can choose 
>    _individually_ whether they want to see 'git-xyzzy' or not!)

And

  - it means git aliases have the same form as builtins

  - it means git on Windows has the same interface

(Arguably the latter point ought to be "forces Unix users to use the
same interface as on Windows", but the git-foo forms have been
deprecated on all platforms for a while.  Making Unix and Windows the
same seems a worthwhile goal, though presumably it's irrelevant for
linux kernel people.)

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Takashi Iwai]

At Tue, 26 Aug 2008 10:03:25 -0700 (PDT),
Linus Torvalds wrote:
> 
> 
> 
> On Tue, 26 Aug 2008, David Woodhouse wrote:
> > 
> > Nice emotive response, especially the subtle but unsubstantiated 'silent
> > majority in favour' bit -- but you forgot the part where you were
> > supposed to actually point out a tangible benefit which is achieved by
> > breaking compatibility like this.
> 
> Umm. The 'git-xyzzy' thing has been one of the #1 complaints since pretty 
> much day#1. The number of people complaining about it going away has 
> literally been _much_ smaller than the people who complained about it 
> being there.
> 
> Also, like it or not, it's done. So the argument about "compatibility" is 
> TOTAL AND UTTER BULLSHIT. There is no compatibility, because we already 
> released a major version without them.

Well, you can still install git-* to /usr/bin by specifying
gitexecdir=/usr/bin at make.  So, the compatibility is not lost.

It's just a default configuration issue, IMO.


Takashi

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Petr Baudis]

On Tue, Aug 26, 2008 at 06:29:03PM +0100, Bruce Stephens wrote:
>   - it means git on Windows has the same interface
> 
> (Arguably the latter point ought to be "forces Unix users to use the
> same interface as on Windows", but the git-foo forms have been
> deprecated on all platforms for a while.  Making Unix and Windows the
> same seems a worthwhile goal, though presumably it's irrelevant for
> linux kernel people.)

I actually checked, and my msysgit installation does hardlinking (or at
least pretends to do, and ls -l shows high linkcounts). And somewhat
amusingly, it doesn't appear that 1.6.0 will be released for Windows
anytime soon, though that's of course not relevant from long term
perspective.

				Petr "Pasky" Baudis

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Bruce Stephens]

Petr Baudis <pasky@suse.cz> writes:

[...]

> I actually checked, and my msysgit installation does hardlinking (or at
> least pretends to do, and ls -l shows high linkcounts). And somewhat
> amusingly, it doesn't appear that 1.6.0 will be released for Windows
> anytime soon, though that's of course not relevant from long term
> perspective.

IIRC git.exe knows how to run Tcl scripts (maybe perl and
shell-scripts), and on Windows you need to use "git gui" and things
because "git-gui" won't work.

Re: [PATCH] bash completion: Hide more plumbing commands

[Jakub Narebski]

Petr Baudis <pasky@suse.cz> writes:

> git <tab><tab> still shows way too many commands, some of them
> are clearly plumbing. This patch hides the plumbing commands
> liberally (that is, in special cases, users still might want to
> call one of the hidden commands, a *normal* workflow should never
> involve these, though - and if it does, we have a UI problem anyway).
> 
> Signed-off-by: Petr Baudis <pasky@suse.cz>
> ---
> 
>  contrib/completion/git-completion.bash |   10 ++++++++++
>  1 files changed, 10 insertions(+), 0 deletions(-)
> 
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 89858c2..773d64b 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -386,7 +386,9 @@ __git_porcelain_commands ()
>  		cat-file)         : plumbing;;
>  		check-attr)       : plumbing;;
>  		check-ref-format) : plumbing;;
> +		checkout-index)   : plumbing;;

Clearly plumbing.

>  		commit-tree)      : plumbing;;
> +		count-objects)    : plumbing;;

Plumbing (hyphenated name is a very good hint), but useful to decide
when to repack. I'm partially to leaving it, as I use it from time to
time from CLI.

>  		cvsexportcommit)  : export;;
>  		cvsimport)        : import;;
>  		cvsserver)        : daemon;;
> @@ -395,6 +397,7 @@ __git_porcelain_commands ()
>  		diff-index)       : plumbing;;
>  		diff-tree)        : plumbing;;
>  		fast-import)      : import;;
> +		fast-export)      : export;;

Good catch. BTW. both fast-import and fast-export are plumbing, in a
sense that I don't see how they can be used from command line
(well...)

>  		fsck-objects)     : plumbing;;
>  		fetch-pack)       : plumbing;;
>  		fmt-merge-msg)    : plumbing;;
> @@ -404,6 +407,10 @@ __git_porcelain_commands ()
>  		index-pack)       : plumbing;;
>  		init-db)          : deprecated;;
>  		local-fetch)      : plumbing;;
> +		lost-found)       : deprecated;;

True.

> +		ls-files)         : plumbing;;

IIRC it doesn't have porcelain equivalent.

> +		ls-remote)        : plumbing;;

"git remote show" is porcelain equivalent.

> +		ls-tree)          : plumbing;;

"git show" can be used instead.

>  		mailinfo)         : plumbing;;
>  		mailsplit)        : plumbing;;
>  		merge-*)          : plumbing;;
> @@ -428,6 +435,7 @@ __git_porcelain_commands ()
>  		runstatus)        : plumbing;;
>  		sh-setup)         : internal;;
>  		shell)            : daemon;;
> +		show-ref)         : plumbing;;

Clearly plumbing.

>  		send-pack)        : plumbing;;
>  		show-index)       : plumbing;;
>  		ssh-*)            : transport;;

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Teemu Likonen]

Jeff King wrote (2008-08-26 13:07 -0400):

> On Tue, Aug 26, 2008 at 06:25:13PM +0200, Petr Baudis wrote:
> 
> > > git-<tab><tab> ... what? 140-something commands? I'll better start
> > > looking for alternatives _right now_!
> > 
> > Actually, this is the only realistic argument I can remember at all.
> > Are there any others? I couldn't come up with any - but I didn't do
> > much history digging: others seem to be equally in dark, though.
> 
> The three reasons I can recall are:

Don't know about "original" reasons but filling users' ~/bin isn't nice 
either. I always install all of the self-built git under $HOME. Since 
"make install" (by default) used to fill ~/bin with those 140 git-* 
executables I already configured git to install itself to a custom 
directory. I had to use $GIT_EXEC_PATH and create some symlinks but with 
1.6.0 I don't have to do this anymore. Me happy.

Setting $GIT_EXEC_PATH wasn't a big deal and I can't see it being a big 
deal now, for some other people, to extend their $PATH to include every  
imaginable git-* executable in the system.

BTW I'd also vote for reducing the number of commands printed with "git 
<tab><tab>" bash-completion.

Re: [PATCH] bash completion: Hide more plumbing commands

[Jakub Narebski]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Petr Baudis <pasky@suse.cz> wrote:
> > git <tab><tab> still shows way too many commands, some of them
> > are clearly plumbing. This patch hides the plumbing commands
> > liberally (that is, in special cases, users still might want to
> > call one of the hidden commands, a *normal* workflow should never
> > involve these, though - and if it does, we have a UI problem anyway).
> > 
> > Signed-off-by: Petr Baudis <pasky@suse.cz>
> 
> Acked-by: Shawn O. Pearce <spearce@spearce.org>
> 
> Though I use git ls-remote at least once every other day to see
> what branches are available on my egit/spearce.git fork.  Its ok,
> I guess I can type a few extra characters...

One would think that one can use "git remote show <remote>" instead of
"git ls-remote <remote>", but I'm not sure if it does show also
_untracked_ remote branches.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Nguyen Thai Ngoc Duy]

On 8/27/08, Jeff King <peff@peff.net> wrote:
> On Tue, Aug 26, 2008 at 10:12:55AM -0700, Shawn O. Pearce wrote:
>
>  > I'm the reason why count-objects, ls-tree and checkout-index are
>  > still offered by the bash completion.  And sitting here reading your
>  > email I realized its been _months_ since I last called checkout-index
>  > by hand.  I still run count-objects and ls-tree very so often, but the
>  > average user probably doesn't use ls-tree.
>  >
>  > So yea, these probably should be removed from the completion list.
>  > But I can make a weak argument for keeping count-objects.
>
>
> I think this message shows the conflict in setting up such a list. We
>  want the command set to be as tiny as possible to help new users find
>  their way. But we want the command set to be useful to git power users.
>
>  I wonder if there should be multiple sets of commands for completion,
>  with a minimal set enabled by default, and a "power user" set that
>  exposes extra commands. I dunno. Maybe that is overengineering. I don't
>  even use the bash completion at all.

How about providing a standard set of aliases? All other SCMs I know
do it. You can type it short/quick without depending on bash.
-- 
Duy

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Dominik Brodowski]

Linus,

On Tue, Aug 26, 2008 at 10:03:25AM -0700, Linus Torvalds wrote:
> > Nice emotive response, especially the subtle but unsubstantiated 'silent
> > majority in favour' bit -- but you forgot the part where you were
> > supposed to actually point out a tangible benefit which is achieved by
> > breaking compatibility like this.
> 
> Umm. The 'git-xyzzy' thing has been one of the #1 complaints since pretty 
> much day#1.

But _why_ do they complain? Just whining or real reasons?

> Also, like it or not, it's done. So the argument about "compatibility" is 
> TOTAL AND UTTER BULLSHIT. There is no compatibility, because we already 
> released a major version without them.

Then release a 1.6.0.1. But the major problem is something else: it's that
doing PATH="$PATH:$(git --exec-path) is also deprecated, i.e. that workaround
is to go away in one of the next releases too.

>  - new people don't even learn the mistakes

But new people read "git-diff-tree" in the man pages, and then wonder why
"git-diff-tree" does not work. People read howtos in the Documentation/
directory and wonder why executing "git-diff-tree" does not work. Besides,
why it is a "mistake" to use git-xyzyy? Also, note that 1.5.4.x man pages
uses git-xyzzy form in many many places, not hinting at all of git-xyzyy
being deprecated.

> and there really is zero downside apart from the _trivial_ downside of you 
> just having to add a single PATH thing to your .bashrc or something.

downsides:

- man pages. man git-add for the command "git add" is a bit...
  disappointing.

- lots of documentation using "git-xyzyy"

- the PATH workaround being deprecated

Best,
	Dominik

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Linus Torvalds]

On Tue, 26 Aug 2008, Dominik Brodowski wrote:
> 
> But _why_ do they complain? Just whining or real reasons?

Well, considering that I think the people who complain about the 1.6.0 
behaviour are whining, what does it matter?

People always think their own concerns are so incredibly important. 

I always thought that git-xyzzy was fine. After all, I _did_ it that way 
to begin with. But people complained, and the whole alias thing meant that 
it couldn't be the primary interface _anyway_, so I changed my opinion.

I don't actually personally feel all that strongly, but I _do_ think that 
right now the git-xyzzy proponents are whining. All of their arguments are 
pure and utter CRAP, considering the triviality of

	PATH="$PATH:$(git --exec-path)"

Really. I repeat that mantra over and over, exactly because it makes all 
the whining so _pointless_.

Why do people still whine about this? Really? None of the whiners have 
answered that simple PATH mantra, BECAUSE THEY CANNOT.

So when you ask "why do they complain", look at both sides. Both sides 
complain about totally stupid things.

but the FACT is that git-1.6.0 can work either way. So the people who 
complain about having lost git-xyzzy are the ones that are being stupid. 

At least the ones who complained about "git-<tab><tab>" being scary had a 
_point_.

> Then release a 1.6.0.1. But the major problem is something else: it's that
> doing PATH="$PATH:$(git --exec-path) is also deprecated, i.e. that workaround
> is to go away in one of the next releases too.

NO, IT IS NOT DEPRECATED.

That was a plan. I think that plan got scuttled already. Stop whining!

Can't you understand that people can change plans based on feedback?

Effing whiners. 

		Linus

Re: [PATCH] bash completion: Hide more plumbing commands

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Petr Baudis <pasky@suse.cz> wrote:
>> git <tab><tab> still shows way too many commands, some of them
>> are clearly plumbing. This patch hides the plumbing commands
>> liberally (that is, in special cases, users still might want to
>> call one of the hidden commands, a *normal* workflow should never
>> involve these, though - and if it does, we have a UI problem anyway).
>> 
>> Signed-off-by: Petr Baudis <pasky@suse.cz>
>
> Acked-by: Shawn O. Pearce <spearce@spearce.org>
>
> Though I use git ls-remote at least once every other day to see
> what branches are available on my egit/spearce.git fork.  Its ok,
> I guess I can type a few extra characters...

Revision-requested-by: me

Unless/until we have an easy way to obtain the information "git-ls-files
-u" gives during conflict resolution, ls-files should stay on the list of
commonly used commands.

Re: [PATCH] bash completion: Hide more plumbing commands

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > Petr Baudis <pasky@suse.cz> wrote:
> >> git <tab><tab> still shows way too many commands, some of them
> >> are clearly plumbing. This patch hides the plumbing commands
> >> liberally (that is, in special cases, users still might want to
> >> call one of the hidden commands, a *normal* workflow should never
> >> involve these, though - and if it does, we have a UI problem anyway).
> >> 
> >> Signed-off-by: Petr Baudis <pasky@suse.cz>
> >
> > Acked-by: Shawn O. Pearce <spearce@spearce.org>
> >
> > Though I use git ls-remote at least once every other day to see
> > what branches are available on my egit/spearce.git fork.  Its ok,
> > I guess I can type a few extra characters...
> 
> Revision-requested-by: me
> 
> Unless/until we have an easy way to obtain the information "git-ls-files
> -u" gives during conflict resolution, ls-files should stay on the list of
> commonly used commands.

Perhaps users should just do:

  git config --global alias.unmerged 'ls-files -u'

?

Ok, well, maybe git.c should do that for you as a builtin.

-- 
Shawn.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Al Viro]

On Tue, Aug 26, 2008 at 11:19:28AM -0700, Linus Torvalds wrote:
> but the FACT is that git-1.6.0 can work either way. So the people who 
> complain about having lost git-xyzzy are the ones that are being stupid. 
> 
> At least the ones who complained about "git-<tab><tab>" being scary had a 
> _point_.

Well, to be fair, "man git-add for git add is rather unconventional" is
a valid point...

FWIW, personally I couldn't care less as long as manpages *are* there and
we do not end up with something like "oh, just use info / html / some other
weird crap; manpages are not suitable(tm), dontcha know"

Re: [PATCH] bash completion: Hide more plumbing commands

[Daniel Barkalow]

On Tue, 26 Aug 2008, Junio C Hamano wrote:

> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > Petr Baudis <pasky@suse.cz> wrote:
> >> git <tab><tab> still shows way too many commands, some of them
> >> are clearly plumbing. This patch hides the plumbing commands
> >> liberally (that is, in special cases, users still might want to
> >> call one of the hidden commands, a *normal* workflow should never
> >> involve these, though - and if it does, we have a UI problem anyway).
> >> 
> >> Signed-off-by: Petr Baudis <pasky@suse.cz>
> >
> > Acked-by: Shawn O. Pearce <spearce@spearce.org>
> >
> > Though I use git ls-remote at least once every other day to see
> > what branches are available on my egit/spearce.git fork.  Its ok,
> > I guess I can type a few extra characters...
> 
> Revision-requested-by: me
> 
> Unless/until we have an easy way to obtain the information "git-ls-files
> -u" gives during conflict resolution, ls-files should stay on the list of
> commonly used commands.

Doesn't "git status" tell you that? Or do you want the extra info from the 
implicit --stage?

	-Daniel
*This .sig left intentionally blank*

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Linus Torvalds]

On Tue, 26 Aug 2008, Al Viro wrote:
> 
> Well, to be fair, "man git-add for git add is rather unconventional" is
> a valid point...

On the other hand:

 - "man" simply cannot currently handle "man git add", even though there's 
   been some noise to teach it.

 - you can use "git help add" instead, since git itself does understand 
   this. It will just go "man git-add" for you, so that your fingers don't 
   have to type that dash ;)

> FWIW, personally I couldn't care less as long as manpages *are* there and
> we do not end up with something like "oh, just use info / html / some other
> weird crap; manpages are not suitable(tm), dontcha know"

I don't think _that_ is going to happen. You're not the only one who wants 
man-pages.

		Linus

Re: [PATCH] bash completion: Hide more plumbing commands

[Shawn O. Pearce]

Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Tue, 26 Aug 2008, Junio C Hamano wrote:
> > 
> > Unless/until we have an easy way to obtain the information "git-ls-files
> > -u" gives during conflict resolution, ls-files should stay on the list of
> > commonly used commands.
> 
> Doesn't "git status" tell you that? Or do you want the extra info from the 
> implicit --stage?

I think he doesn't want to see the other files that are already
merged successfully.  git status shows them, git ls-files -u
does not.

-- 
Shawn.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Teemu Likonen]

Al Viro wrote (2008-08-26 18:55 +0000):

> Well, to be fair, "man git-add for git add is rather unconventional" is
> a valid point...

True. I'd say that for people familiar with other VCS/SCM tools the 
"$VCS help add" is probably the primary help interface. It works with 
many tools - git, hg, svn and bzr at least.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Al Viro]

On Tue, Aug 26, 2008 at 12:04:51PM -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 26 Aug 2008, Al Viro wrote:
> > 
> > Well, to be fair, "man git-add for git add is rather unconventional" is
> > a valid point...
> 
> On the other hand:
> 
>  - "man" simply cannot currently handle "man git add", even though there's 
>    been some noise to teach it.
> 
>  - you can use "git help add" instead, since git itself does understand 
>    this. It will just go "man git-add" for you, so that your fingers don't 
>    have to type that dash ;)

Yeah...  Actually, it all boils down to YAsrbBogosity.  Namely, rather
dumb conventions for $PATH; it would be much saner if the things worked
as for $CDPATH.  That is,
/<whatever> -> use that as-is
./<whatever> -> use that as-is
../<whatever> -> use that as-is
<anything else> -> try to use <path element>/<anything else> for each
path element.

The difference, of course, is that things like git/subcommand would end up
as /usr/bin/git/subcommand, nicely gathering related stuff together in
obvious place and keeping the size of /usr/bin down.  Without the holy
wars about irregular syntax, etc., etc.

Not that it had been the worst offense against the sanity and taste that
went into sh(1)...

Re: [PATCH] bash completion: Hide more plumbing commands

[Daniel Barkalow]

On Tue, 26 Aug 2008, Shawn O. Pearce wrote:

> Daniel Barkalow <barkalow@iabervon.org> wrote:
> > On Tue, 26 Aug 2008, Junio C Hamano wrote:
> > > 
> > > Unless/until we have an easy way to obtain the information "git-ls-files
> > > -u" gives during conflict resolution, ls-files should stay on the list of
> > > commonly used commands.
> > 
> > Doesn't "git status" tell you that? Or do you want the extra info from the 
> > implicit --stage?
> 
> I think he doesn't want to see the other files that are already
> merged successfully.  git status shows them, git ls-files -u
> does not.

I think it might make sense to support "git status --unmerged" or 
something like that, where it filters the output by the tags it would 
show.

	-Daniel
*This .sig left intentionally blank*

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[H. Peter Anvin]

Jean Delvare wrote:
> 
> Reducing /usr/bin in size was totally worthwhile. Maybe not to you, but
> to the silent majority I am a proud member of, it was. (I'm not saying
> that the path that was taken to get there was optimal, just that the
> goal was sound.)
> 

You keep trying to use the Nixon argument ("silent majority.")  You *do* 
know that it was a rhetorical device used by Nixon's speechwriters to 
push ahead with policies despite compact opposition, don't you?

As far as I can tell, most of the arguments in favour came from fanbois 
of $OTHER_SCM which went along the lines of "why does git need all this 
stuff in /usr/bin, when $OTHER_SCM doesn't?"  It had nothing to do with 
reality, of course; it was just a difference between git and $OTHER_SCM 
which they choose to pick on.

	-hpa

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Mon, Aug 25, 2008 at 04:41:57PM -0700, Junio C Hamano wrote:
>
>> > Umm.  What exactly makes you feel you should ignore the discussions we had 
>> > around the issues on the git and msysgit mailing list?
>> 
>> Well, this was partly my fault, as I did not make it clear in this part
>> that beating the horse that has been dead for two years is not a
>> productive way to spend out time.  I however did, in the part David did
>> not quote, try to make it clear:
>> 
>>   That's all history now anyway.  We should try to do better the next time,
>>   which is much more important, and that is the topic of this message.
>
> I don't want to stir up this discussion too much; I am sure you have
> many more important things to be working on. But I did want to make one
> observation.
>
> One side of the argument, I see a lot of "I would prefer it this way."
> And on the other side I see a lot of "this discussion is already
> history" and "but I do not care personally that much."
>
> It makes me wonder why nobody has said "no, really, I prefer it without
> the programs in /bin." Are they simply confident that the decision has
> been made, and don't feel the need to say something?

To me, one of the two saddest part of this story is this.

I was among the "don't change anything, get used to it just like old
timers are already used to" camp, when people said that having many
commands in /usr/bin (or $HOME/bin) would scare people and pushed for this
change, around the end of 2005 through early 2006.  The pros-and-cons
wasn't clearly cut-and-dried.  Moving out of /usr/bin has slight technical
merits (e.g. "bash completion not showing 150+ commands but only selected
Porcelains", "not scaring people off", "dashless form is needed if you
want to use global options", and "moving away from dashed form will
eventually let us get rid of copies on systems without hardlinks even from
under /usr/libexec/git-core").  But I do not think the advantage was so
great.

When I hear something like what David Woodhouse said in this thread, I
should be feeling "People -- those of you who claimed to be the silent
majority -- see, I told you so!  This is a very bad move".

But I can't.  People who complain _now_ just annoy me even more.  Why
weren't you defending the backward compatibility with me, which you seem
to value it so much, perhaps even more than I did back then?  Why are you
wasting our time bringing it up again, instead of joining the discussion
when it _mattered_ back then?

And I still think there is no great reason to pick one way or the other.
Having everything in /usr/bin does not have any better reason than "it has
been that way from the beginning", and that certainly is not a reason
strong enough to revert this anymore, as the opposition now has "the
latest and greatest was shipped with the new layout" which is an equally
valid argument.

Another, even more sad part of this story is that the thread was confused
into talking about the change that has already happened, which is a total
offtopic, and wasted even more time from people.

Read the subject line again, and notice that we are not talking about
/usr/bin vs /usr/libexec/git-core; the request-for-discussion was about
removing "git-add" and friends from /usr/libexec/git-core/, so that we do
not have to even have these many hardlinks there.  Except for Linus (and
obviously myself who started the thread), I saw nobody expressed any
opinion on it.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Steven Rostedt]

On Tue, 26 Aug 2008, Stefan Richter wrote:

> A Large Angry SCM wrote:
> > Jean Delvare wrote:
> >> On Mon, 25 Aug 2008 22:58:37 -0400, A Large Angry SCM wrote:
> >>> David Woodhouse wrote:
> >>>>   (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.
> >>> Acked-by: A Large Angry SCM <gitzilla@gmail.com>
> [...]
> > Do some research; [...]
> 
> ...the plan to move git-foo out of /usr/bin has been discussed and 
> wrapped up quite a while ago (am I confident to say without being 
> subscriber of git@vger.k'org myself).
> 

I'm sorry, but this thread reminds me of the day Aurther Dent's house was 
going to be destroyed for a by-way. ;-)

-- Steve

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jeff King]

On Tue, Aug 26, 2008 at 01:39:30PM -0700, Junio C Hamano wrote:

> But I can't.  People who complain _now_ just annoy me even more.  Why
> weren't you defending the backward compatibility with me, which you seem
> to value it so much, perhaps even more than I did back then?  Why are you
> wasting our time bringing it up again, instead of joining the discussion
> when it _mattered_ back then?

Yes, I was hoping my message would help provoke them to say "here is why
I did not do it back then, and why this should be revisited now". But
all it seems to have done is bring up more arguments that should have
been given back then. So for that I apologize, since I know that is
exactly what you did not want to read. ;)

> Read the subject line again, and notice that we are not talking about
> /usr/bin vs /usr/libexec/git-core; the request-for-discussion was about
> removing "git-add" and friends from /usr/libexec/git-core/, so that we do
> not have to even have these many hardlinks there.  Except for Linus (and
> obviously myself who started the thread), I saw nobody expressed any
> opinion on it.

I was slightly negative on the change at the time of "/usr/bin vs
/usr/libexec/git-core" and I planned to put "git --exec-path" in my
PATH. But I gave the new way a try, and I have not been very bothered.
So let me say that I really don't care much what happens with libexec,
and you can hold me to that when the next flame-war breaks out if such a
change is implemented. Now you have three opinions. :)

I really was just concerned that we are rejecting legitimate, popular
concerns because of a grumpy "you missed the deadline" stance, when
perhaps there is a good reason (which I am still waiting to hear) that
those concerns missed the deadline.

-Peff

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Willy Tarreau]

On Tue, Aug 26, 2008 at 01:16:24PM -0400, Jeff King wrote:
> On Tue, Aug 26, 2008 at 10:12:55AM -0700, Shawn O. Pearce wrote:
> 
> > I'm the reason why count-objects, ls-tree and checkout-index are
> > still offered by the bash completion.  And sitting here reading your
> > email I realized its been _months_ since I last called checkout-index
> > by hand.  I still run count-objects and ls-tree very so often, but the
> > average user probably doesn't use ls-tree.
> > 
> > So yea, these probably should be removed from the completion list.
> > But I can make a weak argument for keeping count-objects.
> 
> I think this message shows the conflict in setting up such a list. We
> want the command set to be as tiny as possible to help new users find
> their way. But we want the command set to be useful to git power users.
> 
> I wonder if there should be multiple sets of commands for completion,
> with a minimal set enabled by default, and a "power user" set that
> exposes extra commands. I dunno. Maybe that is overengineering. I don't
> even use the bash completion at all.

The problem is not caused by the number of commands, but by their
complexity. I need completion because it's hard to type their very
long names without making mistakes (not counting the long options).
"git am" is fine with me, but "git format-patch" is quite boring to
type. It's also interesting to note that short names are currently
in place for less commonly used commands : git-rm, git-mv, git-gc.

Willy

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Dominik Brodowski]

Linus,

On Tue, Aug 26, 2008 at 11:19:28AM -0700, Linus Torvalds wrote:
> 	PATH="$PATH:$(git --exec-path)"
> 
> Really. I repeat that mantra over and over, exactly because it makes all 
> the whining so _pointless_.

It does indeed make it pointless, as long this PATH thing is staying.
However, some of the arguments (finally!) mentioned in this thread make me
worrying otherwise, for they become moot if this PATH thing stays. Also,

> NO, IT IS NOT DEPRECATED.

this is the first time -- despite repeated questions -- that the deprecation
notice got deprecated.

> Can't you understand that people can change plans based on feedback?

Indeed I can understand it. If people tell about it.

Best,
	Dominik

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

>> ... But the major problem is something else: it's that
>> doing PATH="$PATH:$(git --exec-path) is also deprecated, i.e. that workaround
>> is to go away in one of the next releases too.
>
> NO, IT IS NOT DEPRECATED.
>
> That was a plan. I think that plan got scuttled already. Stop whining!
>
> Can't you understand that people can change plans based on feedback?
>
> Effing whiners. 

I do not think "the plan got scuttled *already*" before you said so.  It
was the purpose for this thread to discuss it.

You effectively vetoed the plan with your statement just now, and that
settles it.  We can now officially declare the plan got scuttled and we
can all go back to our happy lives ;-).

Thanks.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Linus Torvalds]

On Tue, 26 Aug 2008, Junio C Hamano wrote:
> 
> I do not think "the plan got scuttled *already*" before you said so.  It
> was the purpose for this thread to discuss it.
>
> You effectively vetoed the plan with your statement just now, and that 
> settles it.

I wouldn't say I vetoed i, but wasn't it pretty obvious from the whole 
discussion that a fair number of people want to keep git-xyzzy?

So getting rid of git-xyzzy altogether would seem to be stupid, and not 
listening to users.

So I'm not "vetoing" it, but I don't think git maintainers (past _or_ 
current ;) have been stupid, or unable to listen to people, and as such I 
think the end result is pretty obvious.

			Linus

Re: [PATCH] bash completion: Hide more plumbing commands

[Matthieu Moy]

Petr Baudis <pasky@suse.cz> writes:

> git <tab><tab> still shows way too many commands, some of them
> are clearly plumbing. This patch hides the plumbing commands
> liberally (that is, in special cases, users still might want to
> call one of the hidden commands, a *normal* workflow should never
> involve these, though - and if it does, we have a UI problem anyway).

Is it possible to have the completion not show them by default, but
fall back to them if no other completion is found?

-- 
Matthieu

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Perry Wagle]

On Aug 26, 2008, at 11:19 AM, Linus Torvalds wrote:
> I don't actually personally feel all that strongly, but I _do_ think  
> that
> right now the git-xyzzy proponents are whining. All of their  
> arguments are
> pure and utter CRAP, considering the triviality of
>
> 	PATH="$PATH:$(git --exec-path)"

Scripts.  Remote scripts.  Scripts running as arbitrary users.

I'm trying to upgrade the git that our scripts use, and having the  
users modify their paths doesn't work.

Not that horrible to fix some other way, but still a rude thing to  
wake up to one day. (ie, today)

-- Perry Wagle (wagle@mac.com)

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Perry Wagle]

On Aug 26, 2008, at 1:39 PM, Junio C Hamano wrote:

> But I can't.  People who complain _now_ just annoy me even more.  Why
> weren't you defending the backward compatibility with me, which you  
> seem
> to value it so much, perhaps even more than I did back then?  Why  
> are you
> wasting our time bringing it up again, instead of joining the  
> discussion
> when it _mattered_ back then?

I wasn't around back then.  I came in a year ago to write some git  
scripts (mostly for hooks).  I saw that lots of scripts (including  
gitweb and the sample hooks) used the git- form, and some didn't.  I  
found that I liked the git- form, since it permitted command and man  
page name completion, so I did that.

Today I literally wake up to find that I now gotta go fix all those  
scripts, upgrade git-web, and whatever other *scripts* used the now  
obsolete git- form.  Sorry, I skim the git list every week or three.

The doctor says I'll live, and be back to health in a few hours.  But  
there will be a doctor bill.  Can I send it to you?  8)

-- Perry Wagle (wagle@mac.com)

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Nicolas Pitre]

On Tue, 26 Aug 2008, Junio C Hamano wrote:

> Read the subject line again, and notice that we are not talking about
> /usr/bin vs /usr/libexec/git-core; the request-for-discussion was about
> removing "git-add" and friends from /usr/libexec/git-core/, so that we do
> not have to even have these many hardlinks there.  Except for Linus (and
> obviously myself who started the thread), I saw nobody expressed any
> opinion on it.

Don't deprecate git-foo and leave them in $gitexecdir as things are now.
That's the best compromise IMHO.

Those who want git-foo can have it via several and easy means.  Those 
who want 'git foo' have it by default which IMHO is pretty sane (the 
other way around is less easy so 'git foo' being the default is the most 
sensible alternative).

Platforms where filesystem links are not available simply don't have to 
support the git-foo form, period.  I doubt users of such platforms will 
care much.

All the rest is only bikeshedding.


Nicolas

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Matthew Wilcox]

On Tue, Aug 26, 2008 at 01:39:30PM -0700, Junio C Hamano wrote:
> When I hear something like what David Woodhouse said in this thread, I
> should be feeling "People -- those of you who claimed to be the silent
> majority -- see, I told you so!  This is a very bad move".
> 
> But I can't.  People who complain _now_ just annoy me even more.  Why
> weren't you defending the backward compatibility with me, which you seem
> to value it so much, perhaps even more than I did back then?  Why are you
> wasting our time bringing it up again, instead of joining the discussion
> when it _mattered_ back then?

We didn't know the conversation was going on.  Why should we?  We only
use the tool, not develop it.  I'm also not on the mailing lists for
mutt, vim, gcc, binutils, openssh, grep, xchat, mozilla, gnome, xpdf or
any of the dozens of other programs I use on a daily basis.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[A Large Angry SCM]

Linus Torvalds wrote:

> 
> So live with it, and just add the 
> 
> 	PATH="$PATH:$(git --exec-path)"
> 
> as a "compatibility layer" to your own setup already. There is no 
> downside, and I think there _is_ a big upside, and no, it's not just about 
> "/usr/bin" being smaller.

Actually, this is acceptable since I set gitexecdir to $(bindir) in my 
make invocation.

*BUT* the recent discussion of not creating the hardlinks in 
git/core/libexec, introducing obnoxious warnings when using the dashed 
forms, and eventually having the git binary error when invoked as a 
dashed command is NOT acceptable. The discussion that happened in 
November and December 2006 was only about about moving the executables 
out of /usr/bin, not the completely disabling of the dashed forms for 
those users and distributions that want them.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jay Soffian]

On Tue, Aug 26, 2008 at 5:03 PM, Jeff King <peff@peff.net> wrote:
> I was slightly negative on the change at the time of "/usr/bin vs
> /usr/libexec/git-core" and I planned to put "git --exec-path" in my
> PATH. But I gave the new way a try, and I have not been very bothered.
> So let me say that I really don't care much what happens with libexec,
> and you can hold me to that when the next flame-war breaks out if such a
> change is implemented. Now you have three opinions. :)

+1 on removing the links and I will say this: this change finally
motivated me to switch my login shell from tcsh (12 years I've been
using it!) to bash so I could use the completions and I'm happier for
it. So thank you git. :-)

j.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Ulrich Windl]

On 26 Aug 2008 at 18:45, Andi Kleen wrote:

> git<space><tab><tab>.... what? 140-something commands? etc.etc.
> 

Hi!

Just let me throw in one thought:

Whether files in /usr/bin, or command completions: Long linear lists are a thing 
humans don't like. For the directory issue, one could (assuming a two-level 
hierarchy) take the square root of the number of binaries and create that many 
directories to put the files in (in theory). Likewise for git<TAB><TAB> one could 
deduce the list by making two levels out of one (i.e. sub-sommands).

In HP-UX many commands (or "subsystems") use /opt/<subsys>/{bin,sbin} to place 
their binaries. PATH usually does not contain all of them. That's against Linux 
philosophy I think, and I really don't like huge PATHs, but it may be one solution 
to reduce the size of linear lists. It won't help against the git<TAB><TAB> issue 
directly, however.

Regards,
Ulrich

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Ulrich Windl]

On 26 Aug 2008 at 19:27, Andi Kleen wrote:

[...]
> I was assuming someone thinking about using git. At some point
> they will do the git<space><tab><tab> thing and be scared away.
[...]

Hi!

Honestly I think, the user will type "git<ENTER>" first.

Ulrich

Re: [RFD] On deprecating "git-foo" for builtins

[Jean Delvare]

Hi Peter,

On Tue, 26 Aug 2008 13:14:59 -0700, H. Peter Anvin wrote:
> Jean Delvare wrote:
> > 
> > Reducing /usr/bin in size was totally worthwhile. Maybe not to you, but
> > to the silent majority I am a proud member of, it was. (I'm not saying
> > that the path that was taken to get there was optimal, just that the
> > goal was sound.)
> 
> You keep trying to use the Nixon argument ("silent majority.")  You *do* 
> know that it was a rhetorical device used by Nixon's speechwriters to 
> push ahead with policies despite compact opposition, don't you?

No, I don't. What I know is that people who are happy about a decision
usually don't tell about it and just take it for good and granted and
move to something else. You almost always only hear people who are
unhappy about decisions. Which means that comparing the amount of
noise made by the two groups is not fair. For a fair comparison, you
need to ask before doing the change, or if you have already done it, you
have to revert it and see if it generates more complaints than the
original change did (and even that is not totally fair, as some people
will complain because of the double change rather than the decision
itself.)

Anyway, the "silent majority" is no longer silent. If it were, this
discussion thread wouldn't be 60 posts long.

> As far as I can tell, most of the arguments in favour came from fanbois 
> of $OTHER_SCM which went along the lines of "why does git need all this 
> stuff in /usr/bin, when $OTHER_SCM doesn't?"  It had nothing to do with 
> reality, of course; it was just a difference between git and $OTHER_SCM 
> which they choose to pick on.

I see no point in limiting ourselves to SCMs. There are many other
categories of software which have internal commands. I'm using many of
these every day: trac, quilt, lftp. The fact is that none of these have
a hundred extra entries in /usr/bin as git does. trac has one, quilt
has two, lftp has three. So, git does (or used to do) things in a way
that differs from most other tools do.

OTOH, speaking of SCMs, I clearly remember of an old SCM (was it RCS?)
which exposed internal commands "ci" and "co" in the PATH and that
caused great frustration to me several times (notice how near the C and
V are on the keyboard.) I was very happy to see that this namespace
pollution was gone with CVS. Not so happy to see that it was partly back
with SVN (9 binaries in /usr/bin). And frankly unhappy to see that it
was one order of magnitude worse with git.

OK, I'm done with this discussion now. I'm sure everyone involved has
better things to spend their time on.

-- 
Jean Delvare

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Andreas Ericsson]

Jean Delvare wrote:
> On Tue, 26 Aug 2008 18:50:25 +0200, Takashi Iwai wrote:
>> At Tue, 26 Aug 2008 18:23:49 +0200,
>> Jean Delvare wrote:
>>> On Tue, 26 Aug 2008 16:59:58 +0100, David Woodhouse wrote:
>>>> On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote:
>>>>> It's pretty normal to see opponents of a decision like this complain
>>>>> loudly when it lands on their system, whereas the silent majority in
>>>>> favour will be happy to see the change finally implemented but reluctant
>>>>> to stir up the discussion again.
>>>>>
>>>>> I don't think new arguments are brought to the discussion, just new
>>>>> people, who are temporarily inconvened by a change towards sanity.
>>>> Nice emotive response, especially the subtle but unsubstantiated 'silent
>>>> majority in favour' bit -- but you forgot the part where you were
>>>> supposed to actually point out a tangible benefit which is achieved by
>>>> breaking compatibility like this.
>>>>
>>>> And no, reducing the size of /usr/bin by a tiny fraction isn't really a
>>>> worthwhile benefit -- in reality, the 'silent majority' really couldn't
>>>> give a monkey's left testicle about that, and breakage caused by the
>>>> gratuitous change _far_ outweighs any minuscule improvement.
>>> Reducing /usr/bin in size was totally worthwhile. Maybe not to you, but
>>> to the silent majority I am a proud member of, it was. (I'm not saying
>>> that the path that was taken to get there was optimal, just that the
>>> goal was sound.)
>>>
>>> I just can't think of any other tool which installs over 100 binaries
>>> (or scripts, that's the same) in /usr/bin. Can you?
>> netpbm has almost 300 in /usr/bin.
> 
> Ouch. (I guess I shouldn't have asked.)
> 
> Does netpbm do anything convert (ImageMagick) doesn't? I'd be happy to
> get rid of netpbm.
> 

netpbm-progs (the rpm containing all the 320 programs in /usr/bin) is
required for xmlto to function properly, which in turn is necessary
to build the git documentation.

This is on Fedora 9, btw.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[H. Peter Anvin]

Ulrich Windl wrote:
> 
> In HP-UX many commands (or "subsystems") use /opt/<subsys>/{bin,sbin} to place 
> their binaries. PATH usually does not contain all of them. That's against Linux 
> philosophy I think, and I really don't like huge PATHs, but it may be one solution 
> to reduce the size of linear lists. It won't help against the git<TAB><TAB> issue 
> directly, however.
> 

/opt is part of the Filesystem Hierarchy Standard which defines layouts 
on Linux systems.  It is generally not used for binaries included in 
distributions or otherwise managed via distribution package managers, 
however.

	-hpa

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jean Delvare]

On Wed, 27 Aug 2008 09:42:44 +0200, Andreas Ericsson wrote:
> Jean Delvare wrote:
> > On Tue, 26 Aug 2008 18:50:25 +0200, Takashi Iwai wrote:
> >> netpbm has almost 300 in /usr/bin.
> > 
> > Ouch. (I guess I shouldn't have asked.)
> > 
> > Does netpbm do anything convert (ImageMagick) doesn't? I'd be happy to
> > get rid of netpbm.
> > 
> 
> netpbm-progs (the rpm containing all the 320 programs in /usr/bin) is
> required for xmlto to function properly, which in turn is necessary
> to build the git documentation.
> 
> This is on Fedora 9, btw.

On openSuse systems it is required by sax2-gui only. But just because
it is used by these 2 packages doesn't mean that ImageMagick's convert
can't be used instead. Someone would need to check what exactly xmlto
and sax2-gui use in netpbm and whether convert could be used instead.
I'd do if I only I had the time... :/

-- 
Jean Delvare

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Andreas Ericsson]

H. Peter Anvin wrote:
> Jean Delvare wrote:
>>
>> Reducing /usr/bin in size was totally worthwhile. Maybe not to you, but
>> to the silent majority I am a proud member of, it was. (I'm not saying
>> that the path that was taken to get there was optimal, just that the
>> goal was sound.)
>>
> 
> You keep trying to use the Nixon argument ("silent majority.")  You *do* 
> know that it was a rhetorical device used by Nixon's speechwriters to 
> push ahead with policies despite compact opposition, don't you?
> 
> As far as I can tell, most of the arguments in favour came from fanbois 
> of $OTHER_SCM which went along the lines of "why does git need all this 
> stuff in /usr/bin, when $OTHER_SCM doesn't?"  It had nothing to do with 
> reality, of course; it was just a difference between git and $OTHER_SCM 
> which they choose to pick on.
> 

Well, some new users both here and on #git have been slightly bewildered
about the number of commands the default bash-completion show when typing
git<tab><tab>. If anything, the move is long overdue, or should have
waited until 2.0 where people would expect to have to re-learn quite a lot.

There were, initially, two drawbacks with having the git-<commands> outside
the users $PATH. The first was performance when used from scripts, which
was addressed in November 2005 when the git wrapper was rewritten in C,
prior to the 1.0 release.
The second is the shell-completion, which was added in September 2006,
prior to the 1.5 release.

In retrospect, it would probably have been a good thing to make the move
with the 1.0 release (which would likely have caused the bash and zsh
completion scripts to pop into existence a lot earlier than 1.4.2), or
in 1.5, when both reasons for keeping the commands in the path were simply
not there anymore. 1.5 was also informally nicknamed "the UI release", so
it would have sort of fitted in there, while 1.0 was the first "this is
how git will work for the foreseeable future" release, so anything before
1.0 could be considered beta software with a very flexible and fast-moving
UI.

Worth remembering for the future perhaps, although I know it's easy to
overlook the fact that the inertia of the userbase grows exponentially
with the headcount of the same.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: [PATCH] bash completion: Hide more plumbing commands

[Karl Hasselström]

On 2008-08-26 23:53:40 +0200, Matthieu Moy wrote:

> Petr Baudis <pasky@suse.cz> writes:
>
> > git <tab><tab> still shows way too many commands, some of them are
> > clearly plumbing.
>
> Is it possible to have the completion not show them by default, but
> fall back to them if no other completion is found?

I don't know if it's possible, but it sounds like a great idea.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Krzysztof Halasa]

Kristian Høgsberg <krh@redhat.com> writes:

> It's pretty normal to see opponents of a decision like this complain
> loudly when it lands on their system, whereas the silent majority in
> favour will be happy to see the change finally implemented but reluctant
> to stir up the discussion again.

I'm "sure" the silent majority don't care at all. Git is a program
mostly for a specialized group of people who are perfectly capable of
using either model or customizing the installation at will.

It may be a correctness issue with pro and cons for each model
(something along the lines of "how many devils..."), but it doesn't
matter for the (I'm sure) "silent majority" in practice at
all. Writing this email (let alone reading them all) takes more time
than customizing git config.
-- 
Krzysztof Halasa

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[H. Peter Anvin]

Jay Soffian wrote:
> On Tue, Aug 26, 2008 at 5:03 PM, Jeff King <peff@peff.net> wrote:
>> I was slightly negative on the change at the time of "/usr/bin vs
>> /usr/libexec/git-core" and I planned to put "git --exec-path" in my
>> PATH. But I gave the new way a try, and I have not been very bothered.
>> So let me say that I really don't care much what happens with libexec,
>> and you can hold me to that when the next flame-war breaks out if such a
>> change is implemented. Now you have three opinions. :)
> 
> +1 on removing the links and I will say this: this change finally
> motivated me to switch my login shell from tcsh (12 years I've been
> using it!) to bash so I could use the completions and I'm happier for
> it. So thank you git. :-)
> 

Speaking as a tcsh user, I'm not switching until bash gets the 
equivalent functionality as tcsh aliases, in particular the ability to 
selectively disable wildcard expansion on a command-by-command basis.

	-hpa

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Geert Uytterhoeven]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1731 bytes --]

On Wed, 27 Aug 2008, Jean Delvare wrote:
> On Wed, 27 Aug 2008 09:42:44 +0200, Andreas Ericsson wrote:
> > Jean Delvare wrote:
> > > On Tue, 26 Aug 2008 18:50:25 +0200, Takashi Iwai wrote:
> > >> netpbm has almost 300 in /usr/bin.
> > > 
> > > Ouch. (I guess I shouldn't have asked.)
> > > 
> > > Does netpbm do anything convert (ImageMagick) doesn't? I'd be happy to
> > > get rid of netpbm.
> > 
> > netpbm-progs (the rpm containing all the 320 programs in /usr/bin) is
> > required for xmlto to function properly, which in turn is necessary
> > to build the git documentation.
> > 
> > This is on Fedora 9, btw.
> 
> On openSuse systems it is required by sax2-gui only. But just because
> it is used by these 2 packages doesn't mean that ImageMagick's convert
> can't be used instead. Someone would need to check what exactly xmlto
> and sax2-gui use in netpbm and whether convert could be used instead.
> I'd do if I only I had the time... :/

Great, let's start a witch (nazi? ;-) hunt on any package installing more than
$n binaries in /usr/bin, and any packages depending on it...

Get used to the `choice' you and I have between netpbm and ImageMagick (and
whatever other image manipulation tool), just like the choice between
`git<space><subcmd>' and `git-<subcmd>'.

Now, let's get back to topic...

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Steven Rostedt]

On Tue, 26 Aug 2008, Perry Wagle wrote:
> 
> I'm trying to upgrade the git that our scripts use, and having the  
> users modify their paths doesn't work.
> 
> Not that horrible to fix some other way, but still a rude thing to  
> wake up to one day. (ie, today)
> 

Did you see the yellow bulldozer coming at your house while brushing your 
teeth?

-- Steve

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Matthew Wilcox]

On Wed, Aug 27, 2008 at 08:00:17AM +0200, Ulrich Windl wrote:
> In HP-UX many commands (or "subsystems") use /opt/<subsys>/{bin,sbin} to place 
> their binaries. PATH usually does not contain all of them. That's against Linux 
> philosophy I think, and I really don't like huge PATHs, but it may be one solution 
> to reduce the size of linear lists. It won't help against the git<TAB><TAB> issue 
> directly, however.

In HP-UX, the default shell has a line length limit that is smaller than
the length of $PATH.  Be in awe of enterprise scalability.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Perry Wagle]

On Aug 26, 2008, at 11:00 PM, Ulrich Windl wrote:
> On 26 Aug 2008 at 18:45, Andi Kleen wrote:
>> git<space><tab><tab>.... what? 140-something commands? etc.etc.
> Whether files in /usr/bin, or command completions: Long linear lists  
> are a thing
> humans don't like.

Bash and other shells use hash tables to store the commands in the PATH.

Doing git-<tab> was shocking to me at first, but it also showed me a  
list of commands for me to learn.

Now I guess that when everything's fixed up, I'll have to put in a  
space instead of a dash to get exactly the same thing.

What difference did changing the dash to a space make?

-- Perry

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jeff King]

On Wed, Aug 27, 2008 at 12:43:23PM -0700, Perry Wagle wrote:

> Doing git-<tab> was shocking to me at first, but it also showed me a list 
> of commands for me to learn.
>
> Now I guess that when everything's fixed up, I'll have to put in a space 
> instead of a dash to get exactly the same thing.
>
> What difference did changing the dash to a space make?

Did you miss the part of the thread about how it's not exactly the same
thing, but rather substantially fewer commands (and there is even
additional discussion about _which_ commands)?

-Peff

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Perry Wagle]

On Aug 27, 2008, at 12:50 PM, Jeff King wrote:

> On Wed, Aug 27, 2008 at 12:43:23PM -0700, Perry Wagle wrote:
>
>> Doing git-<tab> was shocking to me at first, but it also showed me  
>> a list
>> of commands for me to learn.
>>
>> Now I guess that when everything's fixed up, I'll have to put in a  
>> space
>> instead of a dash to get exactly the same thing.
>>
>> What difference did changing the dash to a space make?
>
> Did you miss the part of the thread about how it's not exactly the  
> same
> thing, but rather substantially fewer commands (and there is even
> additional discussion about _which_ commands)?

I guess I did.  Being an optimist, I wouldn't expect the tab  
completion to *lie* and leave things out.

-- Perry

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jeff Garzik]

Willy Tarreau wrote:
> The problem is not caused by the number of commands, but by their
> complexity. I need completion because it's hard to type their very
> long names without making mistakes (not counting the long options).
> "git am" is fine with me, but "git format-patch" is quite boring to
> type. It's also interesting to note that short names are currently
> in place for less commonly used commands : git-rm, git-mv, git-gc.

Indeed.

Also, I type "git-diff-tree" quite a lot.

My fingers find that

	git SPACE diff DASH tree

is slower and less consistent than

	git DASH diff DASH tree

The same with git-format-patch...  We are going from "all dashes" to "a 
mix of space and dashes" which is increasing inconsistency.

	Jeff

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jeff King]

On Wed, Aug 27, 2008 at 04:24:19PM -0400, Jeff Garzik wrote:

> Indeed.
>
> Also, I type "git-diff-tree" quite a lot.
>
> My fingers find that
>
> 	git SPACE diff DASH tree
>
> is slower and less consistent than
>
> 	git DASH diff DASH tree
>
> The same with git-format-patch...  We are going from "all dashes" to "a  
> mix of space and dashes" which is increasing inconsistency.

I have also found the SPACE-DASH slightly harder to type. However, I'm
curious: what are you doing frequently from the commandline with
git-diff-tree that is not just as easily done with git-diff?

-Peff

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jeff Garzik]

Jeff King wrote:
> On Wed, Aug 27, 2008 at 04:24:19PM -0400, Jeff Garzik wrote:
> 
>> Indeed.
>>
>> Also, I type "git-diff-tree" quite a lot.
>>
>> My fingers find that
>>
>> 	git SPACE diff DASH tree
>>
>> is slower and less consistent than
>>
>> 	git DASH diff DASH tree
>>
>> The same with git-format-patch...  We are going from "all dashes" to "a  
>> mix of space and dashes" which is increasing inconsistency.
> 
> I have also found the SPACE-DASH slightly harder to type. However, I'm
> curious: what are you doing frequently from the commandline with
> git-diff-tree that is not just as easily done with git-diff?

I use it to spit out a patch for a specific commit:

	git-diff-tree -p $COMMIT

Though probably someone will now come along and tell me I'm am 
old-timer, and there is a shorter command that accomplishes the same 
thing :)

Regards,

	Jeff

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[H. Peter Anvin]

Perry Wagle wrote:
>> Did you miss the part of the thread about how it's not exactly the  
>> same thing, but rather substantially fewer commands (and there is even
>> additional discussion about _which_ commands)?
> 
> I guess I did.  Being an optimist, I wouldn't expect the tab  
> completion to *lie* and leave things out.

Yes, that sounds, ahem, rude.

	-hpa

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Linus Torvalds]

On Wed, 27 Aug 2008, Jeff Garzik wrote:
> 
> Also, I type "git-diff-tree" quite a lot.

Why?

I'd suggest you just type "git diff" (if you diff two trees) or "git show" 
(if you want to see just one commit) instead.

There is _no_ reason to use diff-tree, it's purely a historical command 
due to how the implementation was done (ie diffing two trees is a very 
different operation from diffing against the index when looked at from an 
implementation standpoint).

		Linus

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jeff King]

On Wed, Aug 27, 2008 at 04:38:13PM -0400, Jeff Garzik wrote:

> I use it to spit out a patch for a specific commit:
>
> 	git-diff-tree -p $COMMIT
>
> Though probably someone will now come along and tell me I'm am old-timer, 
> and there is a shorter command that accomplishes the same thing :)

Actually, that is something that diff-tree does better (a single
tree-ish with git-diff is "compare against working tree"). To do it with
git-diff you would have to use the obscure (and not very shell-friendly)
syntax:

  git diff $COMMIT^!

Although interactively, I tend to use "git show" for this purpose,
though perhaps you intentionally don't want to see the commit message.

Anyway, thank you for satisfying my curiosity.

-Peff

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Matthew Wilcox]

On Wed, Aug 27, 2008 at 04:38:13PM -0400, Jeff Garzik wrote:
> I use it to spit out a patch for a specific commit:
> 
> 	git-diff-tree -p $COMMIT
> 
> Though probably someone will now come along and tell me I'm am 
> old-timer, and there is a shorter command that accomplishes the same 
> thing :)

git-show -p $COMMIT ?

It also gives you the commit message, but that's not a hardship usually
...

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Adrian Bunk]

On Wed, Aug 27, 2008 at 03:05:56PM -0600, Matthew Wilcox wrote:
> On Wed, Aug 27, 2008 at 04:38:13PM -0400, Jeff Garzik wrote:
> > I use it to spit out a patch for a specific commit:
> > 
> > 	git-diff-tree -p $COMMIT
> > 
> > Though probably someone will now come along and tell me I'm am 
> > old-timer, and there is a shorter command that accomplishes the same 
> > thing :)
> 
> git-show -p $COMMIT ?
> 
> It also gives you the commit message, but that's not a hardship usually
> ...

I'm usually using
  git-show --pretty=oneline $COMMIT

cu
Adrian

BTW: I'd love to get a --pretty=noline

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Steven Rostedt]

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

> Perry Wagle wrote:
> >> Did you miss the part of the thread about how it's not exactly the  
> >> same thing, but rather substantially fewer commands (and there is even
> >> additional discussion about _which_ commands)?
> > 
> > I guess I did.  Being an optimist, I wouldn't expect the tab  
> > completion to *lie* and leave things out.
> 
> Yes, that sounds, ahem, rude.


Yes, they are all a bunch of Nazi git fanatics, that Hitler himself would 
have used the space version of git. He sent the Jews off to the 
concentration camps because they insisted on using the dashes.

There, we have a Hitler reference.

CAN WE PLEASE LET THIS THREAD DIE!

-- Steve

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jeff King]

On Thu, Aug 28, 2008 at 12:13:26AM +0300, Adrian Bunk wrote:

> BTW: I'd love to get a --pretty=noline

How about --pretty=format: ?

-Peff

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Linus Torvalds]

On Wed, 27 Aug 2008, Jeff Garzik wrote:
> 
> I use it to spit out a patch for a specific commit:
> 
> 	git-diff-tree -p $COMMIT

Use

	git show $COMMIT

instead, which is shorter and gives you the log too, and uses a pager by 
default. And defaults to HEAD, so you don't even need to say $COMMIT if 
you want to see the top one. IOW, much nicer is so many ways.

Yeah, the "much nicer" obviously does mean "different". If you _rely_ on 
the fact that you don't get a pager (you just want to scroll youself), or 
you really don't want to see what the commit message was all about, then 
'git diff-tree' is obviously "better".

But at least personally, I really don't know when I last wanted to have 
anything else than 'git show' for showing a commit.

			Linus

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Adrian Bunk]

On Wed, Aug 27, 2008 at 05:22:17PM -0400, Jeff King wrote:
> On Thu, Aug 28, 2008 at 12:13:26AM +0300, Adrian Bunk wrote:
> 
> > BTW: I'd love to get a --pretty=noline
> 
> How about --pretty=format: ?

Thanks, that does the trick.  :-)

> -Peff

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Russell King]

On Tue, Aug 26, 2008 at 06:17:05PM -0600, Matthew Wilcox wrote:
> On Tue, Aug 26, 2008 at 01:39:30PM -0700, Junio C Hamano wrote:
> > When I hear something like what David Woodhouse said in this thread, I
> > should be feeling "People -- those of you who claimed to be the silent
> > majority -- see, I told you so!  This is a very bad move".
> > 
> > But I can't.  People who complain _now_ just annoy me even more.  Why
> > weren't you defending the backward compatibility with me, which you seem
> > to value it so much, perhaps even more than I did back then?  Why are you
> > wasting our time bringing it up again, instead of joining the discussion
> > when it _mattered_ back then?
> 
> We didn't know the conversation was going on.  Why should we?  We only
> use the tool, not develop it.  I'm also not on the mailing lists for
> mutt, vim, gcc, binutils, openssh, grep, xchat, mozilla, gnome, xpdf or
> any of the dozens of other programs I use on a daily basis.

Well said Matthew, as a git _user_ I completely agree.

I only found out myself when it got installed on master.kernel.org, and
things that had worked fine for ages suddenly stopped working with no
clear solution.  Useless documentation which refers to the commands
which didn't seem to be in existence anymore was just, to put it mildly,
infuriating, and provided no answer.

That said, I've now updated all my scripts to not use the dashed version,
including on my local machines (which are still using git 1.5.4.x); the
only thing is I can't get out of the habbit of typing 'git-diff-tree -u'
if I want to see a single commit, or 'git-diff-files -u' if I want to
see (almost) everything in my working directory, or 'git-am'.  The
solution is trivial for when the dashed commands finally go away.

alias git-am='git am'
alias git-diff-files='git diff-files'

etc. in ~/.bashrc  So it's no real big hastle for me anymore.

-- 
Russell King

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Russell King]

On Wed, Aug 27, 2008 at 11:27:04AM -0400, Steven Rostedt wrote:
> 
> On Tue, 26 Aug 2008, Perry Wagle wrote:
> > 
> > I'm trying to upgrade the git that our scripts use, and having the  
> > users modify their paths doesn't work.
> > 
> > Not that horrible to fix some other way, but still a rude thing to  
> > wake up to one day. (ie, today)
> > 
> 
> Did you see the yellow bulldozer coming at your house while brushing your 
> teeth?

That is not a valid point of view when you're a git user, and things
suddenly change from working one day, to not working the next _and_
you don't know why the commands you were using have suddenly vanished.

And there is no documentation seemingly available to tell you what to
use instead.

And the available documentation tells you that the commands you were
using are still there.

And no warnings before hand that the commands you were using were
deprecated.

*That* is what is soo abhorrent about this whole business.

How would you feel if, tomorrow, 'ls', 'tar' etc all gave you "command
not found", 'man ls' still gave you a man page for ls(1) but the
command was now actually called 'listfiles' instead ?

Just put 'alias ls=listfiles' in your .bashrc !

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Junio C Hamano]

Steven Rostedt <rostedt@goodmis.org> writes:

> Yes, they are all a bunch of Nazi git fanatics, that Hitler himself would 
> have used the space version of git. He sent the Jews off to the 
> concentration camps because they insisted on using the dashes.
>
> There, we have a Hitler reference.
>
> CAN WE PLEASE LET THIS THREAD DIE!

Yeah, I second this.

The primary topic has already settled, and we will keep git-foo in libexec
even for built-ins.

This offtopic tangent that shouldn't even have started from the beginning
must die now.  It outlived its usefulness even as a place for people to
vent.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Junio C Hamano]

Matthew Wilcox <matthew@wil.cx> writes:

> On Tue, Aug 26, 2008 at 01:39:30PM -0700, Junio C Hamano wrote:
>> When I hear something like what David Woodhouse said in this thread, I
>> should be feeling "People -- those of you who claimed to be the silent
>> majority -- see, I told you so!  This is a very bad move".
>> 
>> But I can't.  People who complain _now_ just annoy me even more.  Why
>> weren't you defending the backward compatibility with me, which you seem
>> to value it so much, perhaps even more than I did back then?  Why are you
>> wasting our time bringing it up again, instead of joining the discussion
>> when it _mattered_ back then?
>
> We didn't know the conversation was going on.  Why should we?  We only
> use the tool, not develop it.  I'm also not on the mailing lists for
> mutt, vim, gcc, binutils, openssh, grep, xchat, mozilla, gnome, xpdf or
> any of the dozens of other programs I use on a daily basis.

Oh, I wasn't talking to you, or "we as git users".  The user side of the
discussion has long been over in another thread titled "[kernel.org users]
README and ChangeLog files" that was started by HPA, and everybody now
knows that the conclusion of the discussion was that 1.6.0 transition was
underadvertised to the end-user community and caused pain.  Sorry about
that, but let's leave it behind.  What has happend has happened.

The discussion in this thread was about how to go forward from here, now
the transition is over.  One of the future directions the transition was
aiming at was removal of git-foo form for built-ins even from the libexec
area -- I was complaining about David's beating an offtopic dead horse in
the above, because it was throwing the thread in an off-track direction,
distracting everybody from discussing what was more important, discussing
constructively if/how to proceed from here.

Now the primary topic of what to do about built-ins have already settled.
We _will_ keep git-foo commands in the libexec area.  We won't be removing
them.

So there is no need to worry.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jeff Garzik]

Linus Torvalds wrote:
> 
> On Wed, 27 Aug 2008, Jeff Garzik wrote:
>> I use it to spit out a patch for a specific commit:
>>
>> 	git-diff-tree -p $COMMIT
> 
> Use
> 
> 	git show $COMMIT
> 
> instead, which is shorter and gives you the log too, and uses a pager by 
> default. And defaults to HEAD, so you don't even need to say $COMMIT if 
> you want to see the top one. IOW, much nicer is so many ways.
> 
> Yeah, the "much nicer" obviously does mean "different". If you _rely_ on 
> the fact that you don't get a pager (you just want to scroll youself), or 
> you really don't want to see what the commit message was all about, then 
> 'git diff-tree' is obviously "better".

'git show' is quite sufficient, as long as I can pipe its output into 
patch(1) or write it to a foo.patch file, which appears to be the case.

git-diff-tree -p was from the old days; I readily admit being a git 
old-timer :)

Anything that reduces my typing is great, and 'git show' is certainly an 
improvement in that regard.

	Jeff, typing with a sprained finger (puppies can be a handful)

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Stefan Richter]

Russell King wrote:
> And no warnings before hand that the commands you were using were
> deprecated.

(a) They weren't deprecated, they were moved into a different directory.

(b) There have been several announcements of the 1.6.0 prereleases and 
the 1.6.0 release crossposted.  Of course somebody forgot to tell you 
what you will learn from these release notes.  Unfair.

(c) There do happen unannounced software updates on shell servers over 
which you don't have control.  Ask for your money back.

(d) "-" -> " "?  Molehill.
-- 
Stefan Richter
-=====-==--- =--- ===--
http://arcgraph.de/sr/

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Perry Wagle]

On Aug 27, 2008, at 4:27 PM, Junio C Hamano wrote:

> Steven Rostedt <rostedt@goodmis.org> writes:
>
>> Yes, they are all a bunch of Nazi git fanatics, that Hitler himself  
>> would
>> have used the space version of git. He sent the Jews off to the
>> concentration camps because they insisted on using the dashes.
>>
>> There, we have a Hitler reference.
>>
>> CAN WE PLEASE LET THIS THREAD DIE!
>
> Yeah, I second this.
>
> The primary topic has already settled, and we will keep git-foo in  
> libexec
> even for built-ins.
>
> This offtopic tangent that shouldn't even have started from the  
> beginning
> must die now.  It outlived its usefulness even as a place for people  
> to
> vent.

I suggested that git<DASH><TAB> used to give the same 143 completions  
that git<SPACE><TAB> would now.  This meant that making any arguments  
that the number was off-putting to newbies did not apply, since you  
had a same number (143)  either way.  Putting stuff in libexec does  
not change the above observation in any fashion.

A response to my observation was that "not everything will show up in  
the latter completion".  I balked at that as it distorted the truth.   
If this distortion would actually take place then I have a real  
complaint.  Not a tangent.

But as long as git<DASH><TAB> does the *same* thing as  
git<SPACE><TAB>, I really do not see why you had to go break my  
scripts on a *minor* revision for what amounts to no reason as all.

Shells *hash* the PATH, so there is no "linear list" issue, and you  
have the *same* behavior for <TAB> completion both ways.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Perry Wagle]

Oh yeah, sorry.  I neglected to mention that my problem was having the  
git- forms in scripts all over an internal network, and having no  
amazingly easy way of fixing them.  I don't know who all copied them.


On Aug 27, 2008, at 4:53 PM, Perry Wagle wrote:

>
> On Aug 27, 2008, at 4:27 PM, Junio C Hamano wrote:
>
>> Steven Rostedt <rostedt@goodmis.org> writes:
>>
>>> Yes, they are all a bunch of Nazi git fanatics, that Hitler  
>>> himself would
>>> have used the space version of git. He sent the Jews off to the
>>> concentration camps because they insisted on using the dashes.
>>>
>>> There, we have a Hitler reference.
>>>
>>> CAN WE PLEASE LET THIS THREAD DIE!
>>
>> Yeah, I second this.
>>
>> The primary topic has already settled, and we will keep git-foo in  
>> libexec
>> even for built-ins.
>>
>> This offtopic tangent that shouldn't even have started from the  
>> beginning
>> must die now.  It outlived its usefulness even as a place for  
>> people to
>> vent.
>
> I suggested that git<DASH><TAB> used to give the same 143  
> completions that git<SPACE><TAB> would now.  This meant that making  
> any arguments that the number was off-putting to newbies did not  
> apply, since you had a same number (143)  either way.  Putting stuff  
> in libexec does not change the above observation in any fashion.
>
> A response to my observation was that "not everything will show up  
> in the latter completion".  I balked at that as it distorted the  
> truth.  If this distortion would actually take place then I have a  
> real complaint.  Not a tangent.
>
> But as long as git<DASH><TAB> does the *same* thing as  
> git<SPACE><TAB>, I really do not see why you had to go break my  
> scripts on a *minor* revision for what amounts to no reason as all.
>
> Shells *hash* the PATH, so there is no "linear list" issue, and you  
> have the *same* behavior for <TAB> completion both ways.
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Felipe Contreras]

On Thu, Aug 28, 2008 at 2:38 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Matthew Wilcox <matthew@wil.cx> writes:
>
>> On Tue, Aug 26, 2008 at 01:39:30PM -0700, Junio C Hamano wrote:
>>> When I hear something like what David Woodhouse said in this thread, I
>>> should be feeling "People -- those of you who claimed to be the silent
>>> majority -- see, I told you so!  This is a very bad move".
>>>
>>> But I can't.  People who complain _now_ just annoy me even more.  Why
>>> weren't you defending the backward compatibility with me, which you seem
>>> to value it so much, perhaps even more than I did back then?  Why are you
>>> wasting our time bringing it up again, instead of joining the discussion
>>> when it _mattered_ back then?
>>
>> We didn't know the conversation was going on.  Why should we?  We only
>> use the tool, not develop it.  I'm also not on the mailing lists for
>> mutt, vim, gcc, binutils, openssh, grep, xchat, mozilla, gnome, xpdf or
>> any of the dozens of other programs I use on a daily basis.
>
> Oh, I wasn't talking to you, or "we as git users".  The user side of the
> discussion has long been over in another thread titled "[kernel.org users]
> README and ChangeLog files" that was started by HPA, and everybody now
> knows that the conclusion of the discussion was that 1.6.0 transition was
> underadvertised to the end-user community and caused pain.  Sorry about
> that, but let's leave it behind.  What has happend has happened.
>
> The discussion in this thread was about how to go forward from here, now
> the transition is over.  One of the future directions the transition was
> aiming at was removal of git-foo form for built-ins even from the libexec
> area -- I was complaining about David's beating an offtopic dead horse in
> the above, because it was throwing the thread in an off-track direction,
> distracting everybody from discussing what was more important, discussing
> constructively if/how to proceed from here.
>
> Now the primary topic of what to do about built-ins have already settled.
> We _will_ keep git-foo commands in the libexec area.  We won't be removing
> them.
>
> So there is no need to worry.

Still, if this is the decision, all the documentation should be
updated, and people should be discouraged to mention the git-foo
commands ever again, otherwise new users would get confused.

-- 
Felipe Contreras

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jeff Garzik]

Felipe Contreras wrote:
> Still, if this is the decision, all the documentation should be
> updated, and people should be discouraged to mention the git-foo
> commands ever again, otherwise new users would get confused.


True.

I scanned my Kernel Hackers' Guide to Git and made sure to kill a few 
straggling references to dash commands:

	http://linux.yyz.us/git-howto.html

Even though my fingers still want to type git DASH foo, feedback from 
gitsters caused me to purge most dash references from the guide a while 
ago.  I'm surprised the git docs were not updated at the same time I was 
being hectored <grin>

Anyway, it's a fair point and lets definite get the straggling docs 
converted and consistent.

Comments on the above URL welcome, even if unrelated to the current 
topic at hand.

Thanks,

	Jeff

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Steven Rostedt]

On Thu, 28 Aug 2008, Russell King wrote:

> On Wed, Aug 27, 2008 at 11:27:04AM -0400, Steven Rostedt wrote:
> > 
> > On Tue, 26 Aug 2008, Perry Wagle wrote:
> > > 
> > > I'm trying to upgrade the git that our scripts use, and having the  
> > > users modify their paths doesn't work.
> > > 
> > > Not that horrible to fix some other way, but still a rude thing to  
> > > wake up to one day. (ie, today)
> > > 
> > 
> > Did you see the yellow bulldozer coming at your house while brushing your 
> > teeth?
> 
> That is not a valid point of view when you're a git user, and things
> suddenly change from working one day, to not working the next _and_
> you don't know why the commands you were using have suddenly vanished.
> 
> And there is no documentation seemingly available to tell you what to
> use instead.

I think you may have totally missed my reference to the beginning of
"The Hitchhikers Guide to the Galaxy", where Aurther saw the Bulldozer 
about to destroy his house. As he layed in front of the bulldozer, he was 
told that he had plenty of time to complain. Aurther replied that the 
posting was in some strange hidden location. Kind of like what release 
notes are.

But I digress, this thread is totally offtopic for users@kernel.org, can 
we finally take it off (as I just did).

-- Steve


> 
> And the available documentation tells you that the commands you were
> using are still there.
> 
> And no warnings before hand that the commands you were using were
> deprecated.
> 
> *That* is what is soo abhorrent about this whole business.
> 
> How would you feel if, tomorrow, 'ls', 'tar' etc all gave you "command
> not found", 'man ls' still gave you a man page for ls(1) but the
> command was now actually called 'listfiles' instead ?
> 
> Just put 'alias ls=listfiles' in your .bashrc !
> 
> -- 
> Russell King
>  Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
>  maintainer of:
> 

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Mike Hommey]

On Wed, Aug 27, 2008 at 04:38:13PM -0400, Jeff Garzik wrote:
> Jeff King wrote:
>> On Wed, Aug 27, 2008 at 04:24:19PM -0400, Jeff Garzik wrote:
>>
>>> Indeed.
>>>
>>> Also, I type "git-diff-tree" quite a lot.
>>>
>>> My fingers find that
>>>
>>> 	git SPACE diff DASH tree
>>>
>>> is slower and less consistent than
>>>
>>> 	git DASH diff DASH tree
>>>
>>> The same with git-format-patch...  We are going from "all dashes" to 
>>> "a  mix of space and dashes" which is increasing inconsistency.
>>
>> I have also found the SPACE-DASH slightly harder to type. However, I'm
>> curious: what are you doing frequently from the commandline with
>> git-diff-tree that is not just as easily done with git-diff?
>
> I use it to spit out a patch for a specific commit:
>
> 	git-diff-tree -p $COMMIT
>
> Though probably someone will now come along and tell me I'm am  
> old-timer, and there is a shorter command that accomplishes the same  
> thing :)

Other than why you use git diff-tree so much, why don't you set 2
letters aliases for your most commonly used commands ?
[alias]
        st = status
        co = checkout
        fp = format-patch
        dt = diff-tree
etc.

Mike

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Ingo Molnar]

* Jeff Garzik <jgarzik@pobox.com> wrote:

> > Yeah, the "much nicer" obviously does mean "different". If you 
> > _rely_ on the fact that you don't get a pager (you just want to 
> > scroll youself), or you really don't want to see what the commit 
> > message was all about, then 'git diff-tree' is obviously "better".
> 
> 'git show' is quite sufficient, as long as I can pipe its output into 
> patch(1) or write it to a foo.patch file, which appears to be the 
> case.

the only time git show is not sufficient for me in practice, the 
following one is:

  git log --pretty=email -p -1

that's when i want to do precise import/export of patches from/to email. 
(but it's rare)

	Ingo

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[David Woodhouse]

On Wed, 2008-08-27 at 16:38 -0700, Junio C Hamano wrote:
> The discussion in this thread was about how to go forward from here, now
> the transition is over.  One of the future directions the transition was
> aiming at was removal of git-foo form for built-ins even from the libexec
> area -- I was complaining about David's beating an offtopic dead horse in
> the above, because it was throwing the thread in an off-track direction,
> distracting everybody from discussing what was more important, discussing
> constructively if/how to proceed from here.

I'm sorry you feel that way. The reason I didn't object back then was
almost certainly because I didn't notice the discussion. I open the git
mailing list folder so infrequently I might as well not be subscribed. 

But even if I _had_ seen the discussion, I might not have replied.
Life's too short to undertake a reasoned critique of every crack-addled
'plan' you see on the Internet. I'm not going to bother arguing with the
next person who asserts that we should turn Linux into a microkernel and
write it in C++, and I would have treated some idiotic plan to break git
in this way with just the same level of interest.

> Now the primary topic of what to do about built-ins have already settled.
> We _will_ keep git-foo commands in the libexec area.  We won't be removing
> them.

Excellent. All we need to do is make sure the distributions all set
$(gitexecdir) to /usr/bin when they upgrade to 1.6.0 -- and could you
also fix it on master.kernel.org please?

I believe we currently have to override $(gitexecdir) at make time --
could we have it as an option to ./configure, please?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

git-show vs git-log (or: git show vs git log)

[Dominik Brodowski]

On Thu, Aug 28, 2008 at 08:51:24AM +0200, Ingo Molnar wrote:
> > 'git show' is quite sufficient, as long as I can pipe its output into 
> > patch(1) or write it to a foo.patch file, which appears to be the 
> > case.
> 
> the only time git show is not sufficient for me in practice, the 
> following one is:
> 
>   git log --pretty=email -p -1
> 
> that's when i want to do precise import/export of patches from/to email. 
> (but it's rare)

git show --pretty=email

Best,
	Dominik

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Junio C Hamano]

David Woodhouse <dwmw2@infradead.org> writes:

> Excellent. All we need to do is make sure the distributions all set
> $(gitexecdir) to /usr/bin when they upgrade to 1.6.0 -- and could you
> also fix it on master.kernel.org please?

Are you trying to irritate me even more?

Although I personally did not particularly like the "out of /usr/bin" move,
this was done by user request.  I now am hated for doing something I was
dragged into doing, not because I wanted the change, but only because many
others wanted it, and you are dreaming that another pointless change will
be made in the other direction?

Get a clue already.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[David Woodhouse]

On Thu, 2008-08-28 at 01:17 -0700, Junio C Hamano wrote:
> David Woodhouse <dwmw2@infradead.org> writes:
> 
> > Excellent. All we need to do is make sure the distributions all set
> > $(gitexecdir) to /usr/bin when they upgrade to 1.6.0 -- and could you
> > also fix it on master.kernel.org please?
> 
> Are you trying to irritate me even more?

Not at all; I'm sorry if that's the effect.

> Although I personally did not particularly like the "out of /usr/bin" move,
> this was done by user request.  I now am hated for doing something I was
> dragged into doing, not because I wanted the change, but only because many
> others wanted it, and you are dreaming that another pointless change will
> be made in the other direction?

I'm not asking you to make another change in upstream git. You've told
us the workaround (gitexecdir=/usr/bin), and that workaround is no
longer going to be deprecated, which is great. It's just up to us to
ensure that we use that workaround when we build git for ourselves, and
to ensure that our distributions also build packages using that
workaround.

Since I believe you're building the git packages used on kernel.org, I
was just asking you to apply the workaround when you build _those_
packages, that's all.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Felipe Contreras]

On Thu, Aug 28, 2008 at 11:32 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Thu, 2008-08-28 at 01:17 -0700, Junio C Hamano wrote:
>> David Woodhouse <dwmw2@infradead.org> writes:
>>
>> > Excellent. All we need to do is make sure the distributions all set
>> > $(gitexecdir) to /usr/bin when they upgrade to 1.6.0 -- and could you
>> > also fix it on master.kernel.org please?
>>
>> Are you trying to irritate me even more?
>
> Not at all; I'm sorry if that's the effect.
>
>> Although I personally did not particularly like the "out of /usr/bin" move,
>> this was done by user request.  I now am hated for doing something I was
>> dragged into doing, not because I wanted the change, but only because many
>> others wanted it, and you are dreaming that another pointless change will
>> be made in the other direction?
>
> I'm not asking you to make another change in upstream git. You've told
> us the workaround (gitexecdir=/usr/bin), and that workaround is no
> longer going to be deprecated, which is great. It's just up to us to
> ensure that we use that workaround when we build git for ourselves, and
> to ensure that our distributions also build packages using that
> workaround.
>
> Since I believe you're building the git packages used on kernel.org, I
> was just asking you to apply the workaround when you build _those_
> packages, that's all.

You are getting it wrong.

If *you* want the git-foo form, then *you* add the git exec dir to your PATH.

The masses should forget about the git-foo form. If you push people
into using git-foo then you are not following git guidelines; you
would be pushing your own agenda.

-- 
Felipe Contreras

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Petr Baudis]

  This thread is starting to seriously irritate even *me* by now, which
is quite a feat...

On Wed, Aug 27, 2008 at 05:05:33PM -0700, Perry Wagle wrote:
> Oh yeah, sorry.  I neglected to mention that my problem was having the  
> git- forms in scripts all over an internal network, and having no  
> amazingly easy way of fixing them.  I don't know who all copied them.

  Should I count for you how many times the $PATH workaround has been
mentioned already? Or the gitexecdir workaround?

> On Aug 27, 2008, at 4:53 PM, Perry Wagle wrote:
> 
> >
> > On Aug 27, 2008, at 4:27 PM, Junio C Hamano wrote:
> >
> >> Steven Rostedt <rostedt@goodmis.org> writes:
> >>
> >>> Yes, they are all a bunch of Nazi git fanatics, that Hitler  
> >>> himself would
> >>> have used the space version of git. He sent the Jews off to the
> >>> concentration camps because they insisted on using the dashes.
> >>>
> >>> There, we have a Hitler reference.
> >>>
> >>> CAN WE PLEASE LET THIS THREAD DIE!

  Intentional invocations of Godwin's Law don't count - sadly. ;-)

> > I suggested that git<DASH><TAB> used to give the same 143  
> > completions that git<SPACE><TAB> would now.  This meant that making  
> > any arguments that the number was off-putting to newbies did not  
> > apply, since you had a same number (143)  either way.  Putting stuff  
> > in libexec does not change the above observation in any fashion.
> >
> > A response to my observation was that "not everything will show up  
> > in the latter completion".  I balked at that as it distorted the  
> > truth.  If this distortion would actually take place then I have a  
> > real complaint.  Not a tangent.
> >
> > But as long as git<DASH><TAB> does the *same* thing as  
> > git<SPACE><TAB>, I really do not see why you had to go break my  
> > scripts on a *minor* revision for what amounts to no reason as all.

  What the hell are you talking about? Did you *try*? git<SPACE><TAB>
does not do the same thing as git<DASH><TAB>, and it has been clearly
stated in this thread several times. It shows only the commands that are
*interesting* for the user, just as $PATH does not include /usr/sbin and
/sbin and /usr/lib/wine because the executables in these directories
just aren't interesting for the users. If you care about all the Git
internals, go read git(1) to see the list of all the plumbing stuff.

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Perry Wagle]

On Aug 28, 2008, at 2:04 AM, Petr Baudis wrote:

>  This thread is starting to seriously irritate even *me* by now, which
> is quite a feat...
>
> On Wed, Aug 27, 2008 at 05:05:33PM -0700, Perry Wagle wrote:
>> Oh yeah, sorry.  I neglected to mention that my problem was having  
>> the
>> git- forms in scripts all over an internal network, and having no
>> amazingly easy way of fixing them.  I don't know who all copied them.
>
>  Should I count for you how many times the $PATH workaround has been
> mentioned already? Or the gitexecdir workaround?

The PATH thing fixes the problem of typing in git-commands at the  
command line, but not for scripts containing git<DASH> commands.  I've  
seen no-one rebut my rebuttal.

Are you suggesting that I break into machines that I don't have access  
to add a export PATH= line to copies of scripts that were written 6  
months ago, and worked just fine until someone decided that "upward  
compatibility" wasn't an important concept?

What other upward compatibilities were broken in the past six months?   
What am I testing for tomorrow when I fix it before releasing an  
upgraded git?  Next month?

I really don't understand this "upward compatibility doesn't matter"  
thing.

>  What the hell are you talking about? Did you *try*? git<SPACE><TAB>
> does not do the same thing as git<DASH><TAB>, and it has been clearly
> stated in this thread several times. It shows only the commands that  
> are
> *interesting* for the user, just as $PATH does not include /usr/sbin  
> and
> /sbin and /usr/lib/wine because the executables in these directories
> just aren't interesting for the users. If you care about all the Git
> internals, go read git(1) to see the list of all the plumbing stuff.

In this thread the new completion thing has been clearly stated both  
ways.

I have one, apparently very authoritative, response in this thread  
assuring me that it will not be the case that the command completion  
space will be restricted in the fashion you support.  I'm not sure who  
to believe.  It might not matter: apparently, one person in the thread  
was forced to make the change we are all responding to here.  When  
does that happen again?

I find the notion that the command completion should give partial  
results an unpleasant concept.  I've been stuck with systems with no  
documentation, but with command completion with that sort of thinking,  
and as a result, and it was very frustrating.

-- Perry

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[David Woodhouse]

On Thu, 2008-08-28 at 03:33 -0700, Perry Wagle wrote:
> Are you suggesting that I break into machines that I don't have access
> to add a export PATH= line to copies of scripts that were written 6  
> months ago, and worked just fine until someone decided that "upward  
> compatibility" wasn't an important concept?

Not at all. But as long as you also refrain from breaking into those
same machines and upgrading them to git 1.6.0, you should be fine.

Or if you _do_ upgrade them to git 1.6.0, you should make sure you build
with gitexecdir=/usr/bin to prevent the breakage.

What distribution are you running on those machines? If they upgrade
their version of git from an earlier version to 1.6.0 in a stable
release without setting gitexecdir=/usr/bin to preserve compatibility,
then the packager needs to be taken out back and shot.

Perhaps you should file a bug in advance, to make sure they're aware of
the issue and make sure that if/when they update to 1.6.0, they set
gitexecdir properly.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Petr Baudis]

I'm removing users@kernel.org from the Cc list since this is far beyond
relevant there.

On Thu, Aug 28, 2008 at 03:33:46AM -0700, Perry Wagle wrote:
> The PATH thing fixes the problem of typing in git-commands at the command 
> line, but not for scripts containing git<DASH> commands.  I've seen no-one 
> rebut my rebuttal.

Huh? $PATH takes effect both on command-line and in scripts. Maybe you
wanted to phrase this paragraph differently.

> Are you suggesting that I break into machines that I don't have access to 
> add a export PATH= line to copies of scripts that were written 6 months 
> ago, and worked just fine until someone decided that "upward compatibility" 
> wasn't an important concept?

No, they worked just fine until someone upgraded Git there. That
$someone needs to take care of this.

> What other upward compatibilities were broken in the past six months?  What 
> am I testing for tomorrow when I fix it before releasing an upgraded git?  
> Next month?
>
> I really don't understand this "upward compatibility doesn't matter" thing.

The deprecation has been announced several times. Yes, we might've done
better job spreading the word and the documentation still needs updates;
from that it's apparent we're lacking at resources here and help is
welcome. Ask your money back or send patches.

> In this thread the new completion thing has been clearly stated both ways.
>
> I have one, apparently very authoritative, response in this thread assuring 
> me that it will not be the case that the command completion space will be 
> restricted in the fashion you support.  I'm not sure who to believe.  It 
> might not matter: apparently, one person in the thread was forced to make 
> the change we are all responding to here.  When does that happen again?

What response is that? I can see only Andi Kleen's post, and it didn't
actually even directly claim that this is the current behaviour. Then
there's bunch of posts showing that it's not the case. Well, I can only
shrug my shoulders.

Since after all, you clearly just feel like flaming and don't actually
_care_ about this issue at all since you would just _try_ it out if this
actually mattered to you.

> I find the notion that the command completion should give partial results 
> an unpleasant concept.  I've been stuck with systems with no documentation, 
> but with command completion with that sort of thinking, and as a result, 
> and it was very frustrating.

Git has documentation.

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Al Viro]

On Thu, Aug 28, 2008 at 11:57:56AM +0300, Felipe Contreras wrote:

> The masses should forget about the git-foo form. If you push people
> into using git-foo then you are not following git guidelines; you
> would be pushing your own agenda.

Egads...  For sarcasm it's far too heavy-handed and if that's for real...
What's next, verbal diarrhea about Diluting the Message(tm)?

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Felipe Contreras]

On Thu, Aug 28, 2008 at 2:54 PM, Al Viro <viro@hera.kernel.org> wrote:
> On Thu, Aug 28, 2008 at 11:57:56AM +0300, Felipe Contreras wrote:
>
>> The masses should forget about the git-foo form. If you push people
>> into using git-foo then you are not following git guidelines; you
>> would be pushing your own agenda.
>
> Egads...  For sarcasm it's far too heavy-handed and if that's for real...
> What's next, verbal diarrhea about Diluting the Message(tm)?

Sorry, I guess I should have made it clearer.

I haven't made my mind about git-foo vs "git foo", but a decision has
been made to deprecate git-foo, and allow it as an option for the
people that really want to use it, right?

So there must have been a reason to deprecate git-foo, if people keep
using git-foo, and distributions keep allowing it, what's the point of
deprecation? It's ok if they keep that usage to themselves, like
'alias ll = ls -l', but it's not something to assume everybody uses.

So either we take back the decision and keep discussing if it's a good
idea to deprecate git-foo, or we go forward and discourage git-foo
completely.

Anything in the middle would just confuse people more, and wouldn't
achieve the purpose of deprecation.

If some script is relying on git-foo, and it has been deprecated, it
should be fixed.

Best regards.

-- 
Felipe Contreras

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Felipe Contreras]

On Thu, Aug 28, 2008 at 4:15 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Thu, Aug 28, 2008 at 2:54 PM, Al Viro <viro@hera.kernel.org> wrote:
>> On Thu, Aug 28, 2008 at 11:57:56AM +0300, Felipe Contreras wrote:
>>
>>> The masses should forget about the git-foo form. If you push people
>>> into using git-foo then you are not following git guidelines; you
>>> would be pushing your own agenda.
>>
>> Egads...  For sarcasm it's far too heavy-handed and if that's for real...
>> What's next, verbal diarrhea about Diluting the Message(tm)?
>
> Sorry, I guess I should have made it clearer.
>
> I haven't made my mind about git-foo vs "git foo", but a decision has
> been made to deprecate git-foo, and allow it as an option for the
> people that really want to use it, right?
>
> So there must have been a reason to deprecate git-foo, if people keep
> using git-foo, and distributions keep allowing it, what's the point of
> deprecation? It's ok if they keep that usage to themselves, like
> 'alias ll = ls -l', but it's not something to assume everybody uses.
>
> So either we take back the decision and keep discussing if it's a good
> idea to deprecate git-foo, or we go forward and discourage git-foo
> completely.
>
> Anything in the middle would just confuse people more, and wouldn't
> achieve the purpose of deprecation.
>
> If some script is relying on git-foo, and it has been deprecated, it
> should be fixed.

Actually, now I think I understand the point of David Woodhouse better.

If the git-foo was supposed to be deprecated in 1.6.0, it should still
work by default, but something to strongly discourage it like a
warning should have been added.

When it becomes truly obsolete, then people can rely on git exec-dir,
which will be disabled by default.

So is it deprecated or obsolete?

-- 
Felipe Contreras

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Paolo Ciarrocchi]

On Thu, Aug 28, 2008 at 3:34 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Thu, Aug 28, 2008 at 4:15 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Thu, Aug 28, 2008 at 2:54 PM, Al Viro <viro@hera.kernel.org> wrote:
>>> On Thu, Aug 28, 2008 at 11:57:56AM +0300, Felipe Contreras wrote:
>>>
>>>> The masses should forget about the git-foo form. If you push people
>>>> into using git-foo then you are not following git guidelines; you
>>>> would be pushing your own agenda.
>>>
>>> Egads...  For sarcasm it's far too heavy-handed and if that's for real...
>>> What's next, verbal diarrhea about Diluting the Message(tm)?
>>
>> Sorry, I guess I should have made it clearer.
>>
>> I haven't made my mind about git-foo vs "git foo", but a decision has
>> been made to deprecate git-foo, and allow it as an option for the
>> people that really want to use it, right?
>>
>> So there must have been a reason to deprecate git-foo, if people keep
>> using git-foo, and distributions keep allowing it, what's the point of
>> deprecation? It's ok if they keep that usage to themselves, like
>> 'alias ll = ls -l', but it's not something to assume everybody uses.
>>
>> So either we take back the decision and keep discussing if it's a good
>> idea to deprecate git-foo, or we go forward and discourage git-foo
>> completely.
>>
>> Anything in the middle would just confuse people more, and wouldn't
>> achieve the purpose of deprecation.
>>
>> If some script is relying on git-foo, and it has been deprecated, it
>> should be fixed.
>
> Actually, now I think I understand the point of David Woodhouse better.
>
> If the git-foo was supposed to be deprecated in 1.6.0, it should still
> work by default, but something to strongly discourage it like a
> warning should have been added.
>
> When it becomes truly obsolete, then people can rely on git exec-dir,
> which will be disabled by default.
>
> So is it deprecated or obsolete?

I quote Junio:
--8<---
We have deprecated the dashed form in early 2006, and announced that 1.6.0
will remove them from $PATH in the 1.5.4 release notes, with instructions
on how to update their scripts before 1.6.0 happens.  Many people knew
about this transition, but they didn't do anything about it.  Since 2005,
git has matured enough that majority of people are using it without
building one themselves, without a chance to even read Release Notes
--8<---

Ciao,
-- 
Paolo
http://paolo.ciarrocchi.googlepages.com/

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Nicolas Pitre]

On Thu, 28 Aug 2008, David Woodhouse wrote:

> On Thu, 2008-08-28 at 01:17 -0700, Junio C Hamano wrote:
> > David Woodhouse <dwmw2@infradead.org> writes:
> > 
> > > Excellent. All we need to do is make sure the distributions all set
> > > $(gitexecdir) to /usr/bin when they upgrade to 1.6.0 -- and could you
> > > also fix it on master.kernel.org please?
> > 
> > Are you trying to irritate me even more?
> 
> Not at all; I'm sorry if that's the effect.
> 
> > Although I personally did not particularly like the "out of /usr/bin" move,
> > this was done by user request.  I now am hated for doing something I was
> > dragged into doing, not because I wanted the change, but only because many
> > others wanted it, and you are dreaming that another pointless change will
> > be made in the other direction?
> 
> I'm not asking you to make another change in upstream git. You've told
> us the workaround (gitexecdir=/usr/bin), and that workaround is no
> longer going to be deprecated, which is great. It's just up to us to
> ensure that we use that workaround when we build git for ourselves, and
> to ensure that our distributions also build packages using that
> workaround.

... effectively denying all those who asked for "git " from _easily_ 
getting it.  OTOH, you can _trivially_ add $(git --exec-path) to your 
$PATH and forget about it.


Nicolas

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Nicolas Pitre]

On Thu, 28 Aug 2008, Nicolas Pitre wrote:

> On Thu, 28 Aug 2008, David Woodhouse wrote:
> 
> > I'm not asking you to make another change in upstream git. You've told
> > us the workaround (gitexecdir=/usr/bin), and that workaround is no
> > longer going to be deprecated, which is great. It's just up to us to
> > ensure that we use that workaround when we build git for ourselves, and
> > to ensure that our distributions also build packages using that
> > workaround.
> 
> ... effectively denying all those who asked for "git " from _easily_ 
> getting it.

By this I mean "git-" out of /usr/bin, before someone replies saying 
that "git " is always available.


Nicolas

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Alex Riesen]

2008/8/28 Ingo Molnar <mingo@elte.hu>:
> * Jeff Garzik <jgarzik@pobox.com> wrote:
>>
>> 'git show' is quite sufficient, as long as I can pipe its output into
>> patch(1) or write it to a foo.patch file, which appears to be the
>> case.
>
> the only time git show is not sufficient for me in practice, the
> following one is:
>
>  git log --pretty=email -p -1
>

"git show --pretty=email", indeed 8-)

> that's when i want to do precise import/export of patches from/to email.
> (but it's rare)

But it does not export them "precisely". You get no patch for
merges (even if there were changes). Try using "git format-patch
--stdout" (or with "-o <directory>" instead of "--stdout", to split in
patches).

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Johannes Schindelin]

Hi,

On Tue, 26 Aug 2008, Petr Baudis wrote:

> On Tue, Aug 26, 2008 at 06:29:03PM +0100, Bruce Stephens wrote:
> >   - it means git on Windows has the same interface
> > 
> > (Arguably the latter point ought to be "forces Unix users to use the
> > same interface as on Windows", but the git-foo forms have been
> > deprecated on all platforms for a while.  Making Unix and Windows the
> > same seems a worthwhile goal, though presumably it's irrelevant for
> > linux kernel people.)
> 
> I actually checked, and my msysgit installation does hardlinking (or at
> least pretends to do, and ls -l shows high linkcounts). And somewhat
> amusingly, it doesn't appear that 1.6.0 will be released for Windows
> anytime soon, though that's of course not relevant from long term
> perspective.

That is correct.  Even more amusingly, it cannot be released ATM because 
of a breakage _caused_ by the move into libexec: on Windows, we _want_ to 
be as relocatable as possible, i.e. not having an _absolute_ exec path 
compiled in.  So we use a relative one.  And that's the rub: from bin/ 
(for "git") and from libexec/git/ (for almost all others), there is no 
single relative path to etc/.

Funny, eh?
Dscho

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Johannes Schindelin]

Hi,

On Tue, 26 Aug 2008, Al Viro wrote:

> Well, to be fair, "man git-add for git add is rather unconventional" is 
> a valid point...

If you're prepared for even more whining, you could send a patch that 
inlines all git commands into Documentation/git.txt...

Ducks,
Dscho

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Johannes Schindelin]

Hi,

On Tue, 26 Aug 2008, Nicolas Pitre wrote:

> On Tue, 26 Aug 2008, Junio C Hamano wrote:
> 
> > Read the subject line again, and notice that we are not talking about
> > /usr/bin vs /usr/libexec/git-core; the request-for-discussion was about
> > removing "git-add" and friends from /usr/libexec/git-core/, so that we do
> > not have to even have these many hardlinks there.  Except for Linus (and
> > obviously myself who started the thread), I saw nobody expressed any
> > opinion on it.
> 
> Don't deprecate git-foo and leave them in $gitexecdir as things are now.
> That's the best compromise IMHO.
> 
> Those who want git-foo can have it via several and easy means.  Those 
> who want 'git foo' have it by default which IMHO is pretty sane (the 
> other way around is less easy so 'git foo' being the default is the most 
> sensible alternative).
> 
> Platforms where filesystem links are not available simply don't have to 
> support the git-foo form, period.  I doubt users of such platforms will 
> care much.
> 
> All the rest is only bikeshedding.

Not wanting to be part of a _silent_ majority, I fully agree, loudly.

Ciao,
Dscho

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Johannes Schindelin]

Hi,

On Wed, 27 Aug 2008, Russell King wrote:

> On Tue, Aug 26, 2008 at 06:17:05PM -0600, Matthew Wilcox wrote:
> > On Tue, Aug 26, 2008 at 01:39:30PM -0700, Junio C Hamano wrote:
> > > When I hear something like what David Woodhouse said in this thread, I
> > > should be feeling "People -- those of you who claimed to be the silent
> > > majority -- see, I told you so!  This is a very bad move".
> > > 
> > > But I can't.  People who complain _now_ just annoy me even more.  Why
> > > weren't you defending the backward compatibility with me, which you seem
> > > to value it so much, perhaps even more than I did back then?  Why are you
> > > wasting our time bringing it up again, instead of joining the discussion
> > > when it _mattered_ back then?
> > 
> > We didn't know the conversation was going on.  Why should we?  We only
> > use the tool, not develop it.  I'm also not on the mailing lists for
> > mutt, vim, gcc, binutils, openssh, grep, xchat, mozilla, gnome, xpdf or
> > any of the dozens of other programs I use on a daily basis.
> 
> Well said Matthew, as a git _user_ I completely agree.

So are you effectively saying that we should have asked on all the mailing 
list of existing and potential Git users to ask their opinions?

Giggling,
Dscho

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Matthew Wilcox]

On Thu, Aug 28, 2008 at 05:34:43PM +0200, Johannes Schindelin wrote:
> On Wed, 27 Aug 2008, Russell King wrote:
> > On Tue, Aug 26, 2008 at 06:17:05PM -0600, Matthew Wilcox wrote:
> > > We didn't know the conversation was going on.  Why should we?  We only
> > > use the tool, not develop it.  I'm also not on the mailing lists for
> > > mutt, vim, gcc, binutils, openssh, grep, xchat, mozilla, gnome, xpdf or
> > > any of the dozens of other programs I use on a daily basis.
> > 
> > Well said Matthew, as a git _user_ I completely agree.
> 
> So are you effectively saying that we should have asked on all the mailing 
> list of existing and potential Git users to ask their opinions?

No.  I'm effectively saying that *you shouldn't break backwards
compatibility*.  Ever.  It only annoys people.

Including:
 - The maintainer who has to listen to all this whining
 - Everyone who gets this thread cc'd in their inbox
 - People who hadn't been informed of the new way of doing things
 - People who thought they'd got their own way and now have to suffer
   the 'silent majority' speaking up.
 - Linus

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Linus Torvalds]

On Thu, 28 Aug 2008, David Woodhouse wrote:
> 
> I'm not asking you to make another change in upstream git. You've told
> us the workaround (gitexecdir=/usr/bin)

No.

That's your _personal_ workaround.

Others DO NOT WANT IT.

I, for example, no longer want git-xyzzy in my path.

So the real workaround is 

 - you compile YOUR OWN VERSION instead of trying to force your stupid 
   opinion on everybody by forcing the default for distros to be 
   _idiotic_, and then you can do that gitexecdir=/usr/bin and wallow in 
   your own shitty inability to teach yourself not to do the dash.

 - or you do - in a _personal_ file - that

	PATH="$PATH:$(git --exec-path)"

   thing, and forget about it, and never ever have to worry about how git 
   was compiled and installed.

The second is obviously the much superior model, exactly because it allows 
those people who do _not_ want to see git-xyzzy to work on the same 
machine.

> Since I believe you're building the git packages used on kernel.org, I
> was just asking you to apply the workaround when you build _those_
> packages, that's all.

Don't be silly. Why are you grand poo-bah? Why cannot you just add your 
PATH to your .bash_profile?

Get over it already. Why the hell are you _still_ whining, after I have 
told you to do that PATH thing at least ten times already?

		Linus

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Linus Torvalds]

On Thu, 28 Aug 2008, Perry Wagle wrote:
> 
> The PATH thing fixes the problem of typing in git-commands at the  
> command line, but not for scripts containing git<DASH> commands.  I've  
> seen no-one rebut my rebuttal.

What drugs are you people on?

Just put it in your .bash_profile or something. It will now work for all 
your scripts.

And for us people who do _not_ want it, we fix the scripts, or we don't 
run them.

		Linus

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Linus Torvalds]

On Thu, 28 Aug 2008, Felipe Contreras wrote:
> 
> If the git-foo was supposed to be deprecated in 1.6.0

Itw as deprecated over a _year_ ago.

> When it becomes truly obsolete, then people can rely on git exec-dir,
> which will be disabled by default.

It _is_ obsolete, but there's a trivial compatibility thing.

Are you happy now? How hard is it to really understand?

		Linus

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Johannes Schindelin]

Hi,

On Thu, 28 Aug 2008, Matthew Wilcox wrote:

> On Thu, Aug 28, 2008 at 05:34:43PM +0200, Johannes Schindelin wrote:
> > On Wed, 27 Aug 2008, Russell King wrote:
> > > On Tue, Aug 26, 2008 at 06:17:05PM -0600, Matthew Wilcox wrote:
> > > > We didn't know the conversation was going on.  Why should we?  We only
> > > > use the tool, not develop it.  I'm also not on the mailing lists for
> > > > mutt, vim, gcc, binutils, openssh, grep, xchat, mozilla, gnome, xpdf or
> > > > any of the dozens of other programs I use on a daily basis.
> > > 
> > > Well said Matthew, as a git _user_ I completely agree.
> > 
> > So are you effectively saying that we should have asked on all the mailing 
> > list of existing and potential Git users to ask their opinions?
> 
> No.  I'm effectively saying that *you shouldn't break backwards
> compatibility*.  Ever.  It only annoys people.

This is something that comes out of a male cow, and from his back exit.

You are saying that something that was deprecated loooong time ago should 
be kept for backwards compatibility reasons.  That cannot hold, and you 
know that.

Anyway, you even failed to address my complaint, namely that Russell did 
not give us a _chance_.  He did not read the mailing list on which the 
issue was discussed -- and again, it is not a compatibility issue.  But he 
wanted to be notified.  Like they say, you cannot have your cake and eat 
it, too.

As to everybody who still wants to complain that git-xyyx is so much 
better than "git xyyx": face it, it's the better solution for almost 
everybody except for you.  Cope with it.

Oh, and I am sorry if it broke your scripts, but they are easy to fix.  I 
know, because I had to fix mine, too.

Ciao,
Dscho

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Russell King]

On Thu, Aug 28, 2008 at 01:53:50AM +0200, Stefan Richter wrote:
> Russell King wrote:
> >And no warnings before hand that the commands you were using were
> >deprecated.
> 
> (a) They weren't deprecated, they were moved into a different directory.

I think Junio will tell you differently on the "deprecation" bit.

> (b) There have been several announcements of the 1.6.0 prereleases and 
> the 1.6.0 release crossposted.  Of course somebody forgot to tell you 
> what you will learn from these release notes.  Unfair.

Cross posting to high traffic mailing lists doesn't guarantee that
it'll be read.  It's the wrong place to do it.

Arguably, though, the lack of information to users on the system affected
is not git maintainers fault.  It's the fault of the admins on that system
not having read the release notes themselves, and warning their users (for
whom git is a *critical* bit of software) that an upgrade is going to take
place, and they should read such-and-such.

Like a note in the system MOTD.

> (c) There do happen unannounced software updates on shell servers over 
> which you don't have control.  Ask for your money back.
> 
> (d) "-" -> " "?  Molehill.

"ls" -> "listfiles" - how would you feel about that change happening
behind your back?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Perry Wagle]

On Aug 28, 2008, at 9:35 AM, Linus Torvalds wrote:

> On Thu, 28 Aug 2008, Perry Wagle wrote:
>>
>> The PATH thing fixes the problem of typing in git-commands at the
>> command line, but not for scripts containing git<DASH> commands.   
>> I've
>> seen no-one rebut my rebuttal.
>
> What drugs are you people on?

No drugs, just that I was expecting people to do more than demonstrate  
to me the excellence of their knee reflex.  Especially you (Linus),  
who supports thinking things out and not depending on debugging tools.

I prefer to think things out and not "coding from the hip".  I can be  
proven wrong, but you are going to have to engage your brain to do  
so.  Threatening me or whacking me with the neural loop from your  
spine to your knee isn't going to cut it.

> Just put it in your .bash_profile or something. It will now work for  
> all
> your scripts.

In terms of continuing to provide me git<DASH><TAB> if I so desire,  
that's an excellent idea, and I've repeatedly said so.

In terms of preserving scripts, thats a filthy hack that only fixes my  
own execution of those scripts, not for other people.  And some people  
don't run bash, so /etc/bashrc *on every system* or whatever doesn't  
actually do it either.  Did you think that out?

> And for us people who do _not_ want it, we fix the scripts, or we  
> don't
> run them.

This is one upward compatibility broken for goofy reasons, at least  
those given in this thread, where there were numerous "ZOMG!  I get  
143 completions!" accompanied by false claims that it was a 143  
element *list* when in fact a *hash table* is used.

But the issue for me is what other upward compatibilities were  
broken?  What am I testing for?  Is is really only that I

     sed s/git-/git<SPACE>/g

on the scripts?  I'm doubting it, given the quality of reasoning and  
lack of respect for upward compatibility on this thread.

Yes, I'm over-killing a molehill, but I see you all building a  
mountain in the distance that I don't feel like climbing.  I haven't  
been paid to do git stuff for months.

-- Perry

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Matthew Wilcox]

On Thu, Aug 28, 2008 at 09:18:53PM +0200, Johannes Schindelin wrote:
> > No.  I'm effectively saying that *you shouldn't break backwards
> > compatibility*.  Ever.  It only annoys people.
> 
> This is something that comes out of a male cow, and from his back exit.

OK, I'm done.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Teemu Likonen]

Perry Wagle wrote (2008-08-28 12:24 -0700):

> Is is really only that I
> 
>     sed s/git-/git<SPACE>/g
> 
> on the scripts?  I'm doubting it, given the quality of reasoning and
> lack of respect for upward compatibility on this thread.

I have come to understand that "git " has quite long time been more 
robust and portable way of writing scripts. They work in both 
configurations so I'd definitely suggest doing "s/git-/git /g" for every 
script. Of course in an interactive shell everyone can use whatever they 
prefer and works at the moment.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Perry Wagle]

On Aug 28, 2008, at 3:42 AM, David Woodhouse wrote:

> On Thu, 2008-08-28 at 03:33 -0700, Perry Wagle wrote:
>> Are you suggesting that I break into machines that I don't have  
>> access
>> to add a export PATH= line to copies of scripts that were written 6
>> months ago, and worked just fine until someone decided that "upward
>> compatibility" wasn't an important concept?
>
> Not at all. But as long as you also refrain from breaking into those
> same machines and upgrading them to git 1.6.0, you should be fine.

I was being over-dramatic in an attempt to get people to at least try  
to think it out.  You did, thanks!

But the actual problem is that I provide a central repository with  
"the current version of git" for us.  I'm not sure who all pulls from  
that repository, but a number of them have finally learned git well  
enough to clamor for 1.6.0.

So it's them upgrading from my repository, not me upgrading for them.

> Or if you _do_ upgrade them to git 1.6.0, you should make sure you  
> build
> with gitexecdir=/usr/bin to prevent the breakage.

That's a hack, which will burn me in less than a year.

> What distribution are you running on those machines? If they upgrade
> their version of git from an earlier version to 1.6.0 in a stable
> release without setting gitexecdir=/usr/bin to preserve compatibility,
> then the packager needs to be taken out back and shot.

I'm the packager.  I didn't upgrade our customized version of git  
because I'm still trying to think it out.

I don't get to break things.  If I break them, I gotta fix them.  I  
haven't been paid to do git stuff for months, and I have a deadline  
tomorrow.  But I gotta act now if I want a chance to live a life  
without the git community breaking upward compatibility on minor  
version releases for completely frivolous reasons.  It wasn't broke,  
but you "fixed" it anyway.  What's next?

I'm more worried about what's next and what's already slipped through  
than this one particular thing.

-- Perry

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Junio C Hamano]

Russell King <rmk@arm.linux.org.uk> writes:

> On Thu, Aug 28, 2008 at 01:53:50AM +0200, Stefan Richter wrote:
>> Russell King wrote:
>> >And no warnings before hand that the commands you were using were
>> >deprecated.
>> 
>> (a) They weren't deprecated, they were moved into a different directory.
>
> I think Junio will tell you differently on the "deprecation" bit.

The short answer is "no, not anymore".

I might have ;-), if you asked me a few days ago, and the topic of this
thread was exactly to decide the answer to that question, which was
concluded with $gmane/93793.

>> (b) There have been several announcements of the 1.6.0 prereleases and 
>> the 1.6.0 release crossposted.  Of course somebody forgot to tell you 
>> what you will learn from these release notes.  Unfair.
>
> Cross posting to high traffic mailing lists doesn't guarantee that
> it'll be read.  It's the wrong place to do it.
>
> Arguably, though, the lack of information to users on the system affected
> is not git maintainers fault.  It's the fault of the admins on that system
> not having read the release notes themselves, and warning their users (for
> whom git is a *critical* bit of software) that an upgrade is going to take
> place, and they should read such-and-such.
>
> Like a note in the system MOTD.

I've heard enough of "the changes in 1.6.0 was underadvertised and caused
users pain".  I am now aware that git has more mature and its userbase has
broadened beyond populations that read release notes (I rarely read
release notes to updates to vim or coreutils either, and that is showing
the maturity of the packages -- nothing to complain about and I am not
complaining).

But so far nobody gave "here is how I would have advertised it", until
you wrote above.  Thanks.

But that is not something _I_ could have done (and no, "I wouldn't have
accepted the change" is not an option at this point).  Are there things
that the maintainer could have done better?

I think it is fair to say that I have vetoed and am still vetoing many "UI
clean-ups" that propose to change things in a way that "should have been
this way for consistency's sake from day one, if there were no existing
user base".  During discussions to shoot down such proposals, I take
opinions from early adopters (that's you, kernel, wine and x.org people)
very seriously, perhaps to the point that outsiders would feel I am giving
them disproportionately large vetoing power.  Sadly, those "opinions from
eraly adopters" are less and less "real" but more "I'd imagine the early
adopters would say..." these days.  The process would work better if early
adopters do their part to help me by speaking up when it matters from time
to time.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Perry Wagle]

On Aug 28, 2008, at 12:52 PM, Teemu Likonen wrote:

> Perry Wagle wrote (2008-08-28 12:24 -0700):
>
>> Is is really only that I
>>
>>    sed s/git-/git<SPACE>/g
>>
>> on the scripts?  I'm doubting it, given the quality of reasoning and
>> lack of respect for upward compatibility on this thread.
>
> I have come to understand that "git " has quite long time been more
> robust and portable way of writing scripts. They work in both
> configurations so I'd definitely suggest doing "s/git-/git /g" for  
> every
> script. Of course in an interactive shell everyone can use whatever  
> they
> prefer and works at the moment.

Sure.  Its an extra fork in git command intensive scripts (and git is  
racey still maybe), but *shrug*.

When I started with git in Fall 2007, the sample scripts and gitweb  
both used git<DASH> and git<SPACE> willy-nilly.  I liked git<DASH>  
better since it was what I used at the command line for the <TAB>  
completion for the commands and for the man pages, and I like being  
meticulously consistent so I can greatly reduce mistakes.

Even as of March 2008 (our last sync with git before the git scripting  
was completed and we got on to other things), the sample scripts and  
gitweb still used the git<DASH> form.  If this has been brewing for  
two years, there shouldn't have been a git<DASH> form in the scripts  
in the standard source *anywhere* for those two years.

There was.  Therefore, you don't get to claim that this was decided  
two years ago, finally done now, and what's Perry's problem anyway?

But, my problem is not git<DASH> vs git<SPACE>, but the slap-dash way  
upward compatibility was broken and the "water over the dam" slippery  
slope rationalizations that refuse to consider reverting.  "You" will  
do it again in the future since you are declaring success here.  And  
"you" have likely done it in the past 6 months.

-- Perry

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Matthew Wilcox]

On Thu, Aug 28, 2008 at 01:10:14PM -0700, Junio C Hamano wrote:
> I think it is fair to say that I have vetoed and am still vetoing many "UI
> clean-ups" that propose to change things in a way that "should have been
> this way for consistency's sake from day one, if there were no existing
> user base".  During discussions to shoot down such proposals, I take
> opinions from early adopters (that's you, kernel, wine and x.org people)
> very seriously, perhaps to the point that outsiders would feel I am giving
> them disproportionately large vetoing power.  Sadly, those "opinions from
> eraly adopters" are less and less "real" but more "I'd imagine the early
> adopters would say..." these days.  The process would work better if early
> adopters do their part to help me by speaking up when it matters from time
> to time.

I think it's fairly clear by now that we aren't shy about sharing our
opinions ... if we're asked for them.  So do we need a git-oldtimers
mailing list where you can post proposals so we can NACK them?

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Petr Baudis]

On Thu, Aug 28, 2008 at 01:10:14PM -0700, Junio C Hamano wrote:
> I think it is fair to say that I have vetoed and am still vetoing many "UI
> clean-ups" that propose to change things in a way that "should have been
> this way for consistency's sake from day one, if there were no existing
> user base".  During discussions to shoot down such proposals, I take
> opinions from early adopters (that's you, kernel, wine and x.org people)
> very seriously, perhaps to the point that outsiders would feel I am giving
> them disproportionately large vetoing power.  Sadly, those "opinions from
> eraly adopters" are less and less "real" but more "I'd imagine the early
> adopters would say..." these days.  The process would work better if early
> adopters do their part to help me by speaking up when it matters from time
> to time.

I think just freezing the UI is not a good answer. Git's UI evolved too
wildly and uncontrollably in the early days and I think in the long run,
tweaking out at least some of the inconsistencies is good idea, IMHO.
Not that I would think there should be any more *major* changes
upcoming, I mean mostly small stuff (all that I hate the
git-checkout/git-reset dichotomy or git-add/git-rm asymetry, touching
this would be just too radical change by now, IMHO).

The only problem I can see with the transition were the deprecation
messages, as was mentioned much earlier in the thread. If it's going
away in few years, Git should start to nag about it now. Then, all whom
it concerns _will_ realize this and slowly transition at their own pace.
Also, maybe we should require all internal references and documentation
updated when *declaring the feature deprecated* (not when removing it),
even if it means delaying the phase-out; that was the other major
complaint in this thread that is worth remembering, I believe.

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Perry Wagle]

On Aug 28, 2008, at 9:37 AM, Linus Torvalds wrote:

> On Thu, 28 Aug 2008, Felipe Contreras wrote:
>>
>> If the git-foo was supposed to be deprecated in 1.6.0
>
> Itw as deprecated over a _year_ ago.

No, it wasn't.  As of March 2008, git<DASH> was still in the sample  
hooks and in git-web.  That was the last time I did anything with git  
scripting.  It was something between then and now that the <DASH>'s  
were finally removed.

Oh wait:

     dhcp-2:git wagle$ grep -r --color git- . | wc -l
         6580
     dhcp-2:git wagle$

No, I'm not going to figure out which are okay, and which aren't.   
I'll just assume that they are all okay, but leave you to wonder.

-- Perry

PS.  Okay, fine!  Here's as far as I got before getting bored:

     grep -r git- . | cat -v | sed "s/^.*\(git-[^ :\")\[($\']*\).*$/ 
\1/" | sort | uniq

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Petr Baudis]

On Thu, Aug 28, 2008 at 01:23:50PM -0700, Perry Wagle wrote:
>
> On Aug 28, 2008, at 12:52 PM, Teemu Likonen wrote:
>
>> I have come to understand that "git " has quite long time been more
>> robust and portable way of writing scripts. They work in both
>> configurations so I'd definitely suggest doing "s/git-/git /g" for every
>> script. Of course in an interactive shell everyone can use whatever they
>> prefer and works at the moment.
>
> Sure.  Its an extra fork in git command intensive scripts (and git is racey 
> still maybe), but *shrug*.

Do you have any details on the races in Git you know about?

This does not mean an extra fork, only extra exec. In case of builtin
commands (which is actually a large majority by now), not even that.

> Even as of March 2008 (our last sync with git before the git scripting was 
> completed and we got on to other things), the sample scripts and gitweb 
> still used the git<DASH> form.  If this has been brewing for two years, 
> there shouldn't have been a git<DASH> form in the scripts in the standard 
> source *anywhere* for those two years.

I agree that this is a problem. Even now, the documentation is using
git- at plenty of places. Patches are welcome, I'm sure.

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Stefan Richter]

Russell King wrote:
> On Thu, Aug 28, 2008 at 01:53:50AM +0200, Stefan Richter wrote:
>> "-" -> " "?  Molehill.
> 
> "ls" -> "listfiles" - how would you feel about that change happening
> behind your back?

I would feel betrayed, then add another alias to .bashrc, then feel 
deeply satisfied by my cunning betrayal of the betrayers, knowing that 
only a true genius hacker could come up with a countermeasure like that.
-- 
Stefan Richter
-=====-==--- =--- ===--
http://arcgraph.de/sr/

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Perry Wagle]

On Aug 28, 2008, at 1:44 PM, Petr Baudis wrote:

> On Thu, Aug 28, 2008 at 01:23:50PM -0700, Perry Wagle wrote:
>>
>> On Aug 28, 2008, at 12:52 PM, Teemu Likonen wrote:
>>
>>> I have come to understand that "git " has quite long time been more
>>> robust and portable way of writing scripts. They work in both
>>> configurations so I'd definitely suggest doing "s/git-/git /g" for  
>>> every
>>> script. Of course in an interactive shell everyone can use  
>>> whatever they
>>> prefer and works at the moment.
>>
>> Sure.  Its an extra fork in git command intensive scripts (and git  
>> is racey
>> still maybe), but *shrug*.
>
> Do you have any details on the races in Git you know about?

Sorry, I should have just left that line out.  But I didn't, so:

Fall of 2007, I'd get spurious reports that the working dir was  
inconsistent when iterating through 612 commits in a script (I was  
converting from quilt/cvs to git) when it wasn't.  I got around most  
of this by sprinkling the script with git-status and git update-index  
--refresh.  My understanding was that it really was the one-second  
granularity of the timestamps on my file system doing it, so nothing  
for me to do at the time.

However, it was really bugging people, so I figured by this time  
someone had found a clever way to fix it, hence the "maybe".

I haven't tried it for a while.

> This does not mean an extra fork, only extra exec. In case of builtin
> commands (which is actually a large majority by now), not even that.

Yeah, I should have deleted that line. 8)


>> Even as of March 2008 (our last sync with git before the git  
>> scripting was
>> completed and we got on to other things), the sample scripts and  
>> gitweb
>> still used the git<DASH> form.  If this has been brewing for two  
>> years,
>> there shouldn't have been a git<DASH> form in the scripts in the  
>> standard
>> source *anywhere* for those two years.
>
> I agree that this is a problem. Even now, the documentation is using
> git- at plenty of places. Patches are welcome, I'm sure.

Heh.

-- Perry

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Perry Wagle]

On Aug 28, 2008, at 1:57 PM, Stefan Richter wrote:

> Russell King wrote:
>> On Thu, Aug 28, 2008 at 01:53:50AM +0200, Stefan Richter wrote:
>>> "-" -> " "?  Molehill.
>> "ls" -> "listfiles" - how would you feel about that change happening
>> behind your back?
>
> I would feel betrayed, then add another alias to .bashrc, then feel  
> deeply satisfied by my cunning betrayal of the betrayers, knowing  
> that only a true genius hacker could come up with a countermeasure  
> like that.

When I started with VMS (ahem) years ago, my buddies handed me eunice  
(a unix like environment) and a big bag of aliases to make my  
environment look like unix.  I did this for years and was happy.

But one day I lost my command shell init scripts, and was left to fend  
for myself with pure VMS commands.  I was completely helpless.  Moral:  
never again will I customize my programming environment to that extent.

Your solution is that sort of over-customization.  Sticking git's  
libexec in your path is too.  I'm still allergic.

-- Perry

PS.  </offtopic>

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jeff King]

On Thu, Aug 28, 2008 at 01:23:50PM -0700, Perry Wagle wrote:

> But, my problem is not git<DASH> vs git<SPACE>, but the slap-dash way  
> upward compatibility was broken and the "water over the dam" slippery  
> slope rationalizations that refuse to consider reverting.  "You" will do 
> it again in the future since you are declaring success here.  And "you" 
> have likely done it in the past 6 months.

I don't think Junio is declaring success. In fact, I think he has sent
several messages saying (paraphrasing of course):

  - this was obviously not done in the best manner possible, because of
    the number of people complaining

  - we will try to do better about notification next time such a change
    is made. Please make suggestions about how to do so.

  - since we have already released and already broken everybody, and
    these people are now complaining on the list, there is not much
    point in trying to notify people of _this_ change now

Junio (and others) have tried to be very careful about breaking
backwards compatibility, especially for scripting interfaces. We thought
sufficient steps were taken this time, but clearly some disagree.

So please stop making specious claims that there are crazy
backwards-incompatibility bugs lurking throughout new versions of git.
If there are, then please find and name them. If not, then I think the
git community would welcome suggestions about how better to notify users
about the rare changes like this one.

-Peff

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Perry Wagle]

On Aug 28, 2008, at 2:23 PM, Jeff King wrote:

> On Thu, Aug 28, 2008 at 01:23:50PM -0700, Perry Wagle wrote:
>
>> But, my problem is not git<DASH> vs git<SPACE>, but the slap-dash way
>> upward compatibility was broken and the "water over the dam" slippery
>> slope rationalizations that refuse to consider reverting.  "You"  
>> will do
>> it again in the future since you are declaring success here.  And  
>> "you"
>> have likely done it in the past 6 months.
>
> I don't think Junio is declaring success. In fact, I think he has sent
> several messages saying (paraphrasing of course):

I did not name anyone, and put "you" in quotes to try to not even  
imply I was pointing at one person.  Several people have declared  
success, but Junio wasn't one of them.  I think (?) that he was just  
the unwilling gunman.  8)

> So please stop making specious claims that there are crazy
> backwards-incompatibility bugs lurking throughout new versions of git.
> If there are, then please find and name them. If not, then I think the
> git community would welcome suggestions about how better to notify  
> users
> about the rare changes like this one.

I now have to TEST to find those crazy backwards-incompatibility bugs  
before I can upgrade us to 1.6.0.  To test, I have to try to imagine  
what I and others were assuming about git.  And this episode means  
that I can't make any assumptions about the sanity of any changes  
since March, which is the version I'm thinking of upgrading.

But note that THIS upward compatibility bug has been declared to not  
be a bug.  Will any others receive the same stamp?

So please put on your engineer hat, and stop talking about "specious  
claims" and hurting feelings.  Heck, I even got Linus himself to ask  
if us people were on drugs, and I didn't take it personally.  At least  
I'm saying something that can be disputed, and not ad hominem like  
Linus.  8)

How to better notify them is to do it on a major release, like Git  
2.0.  THEN, they expect upward compatibility to break.

-- Perry

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Petr Baudis]

It's getting repetitive. :-(

On Thu, Aug 28, 2008 at 02:41:52PM -0700, Perry Wagle wrote:
> I now have to TEST to find those crazy backwards-incompatibility bugs 
> before I can upgrade us to 1.6.0.  To test, I have to try to imagine what I 
> and others were assuming about git.  And this episode means that I can't 
> make any assumptions about the sanity of any changes since March, which is 
> the version I'm thinking of upgrading.

All changes of this kind, including this one, should be carefully
described in the release notes. Since you say you are effectively a Git
packager, you really should be one of the persons who do actually read
them. :-)

You can't ask us to stop making any incompatible changes - Git is still
too young for that and it's UI got evolved, not designed. But we do
document the changes we do, even though we might do a better job
*spreading* the word.

				Petr "Pasky" Baudis

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jeff King]

On Thu, Aug 28, 2008 at 02:41:52PM -0700, Perry Wagle wrote:

>>> But, my problem is not git<DASH> vs git<SPACE>, but the slap-dash way
>>> upward compatibility was broken and the "water over the dam" slippery
>>> slope rationalizations that refuse to consider reverting.  "You" will 
>>> do
>>> it again in the future since you are declaring success here.  And  
>>> "you"
>>> have likely done it in the past 6 months.
>>
>> I don't think Junio is declaring success. In fact, I think he has sent
>> several messages saying (paraphrasing of course):
>
> I did not name anyone, and put "you" in quotes to try to not even imply I 
> was pointing at one person.  Several people have declared success, but 
> Junio wasn't one of them.  I think (?) that he was just the unwilling 
> gunman.  8)

Sorry, I thought you meant "the git community has put these bugs into
git" in the past 6 months. And I don't think that is true.

> I now have to TEST to find those crazy backwards-incompatibility bugs  
> before I can upgrade us to 1.6.0.  To test, I have to try to imagine what 
> I and others were assuming about git.  And this episode means that I can't 
> make any assumptions about the sanity of any changes since March, which is 
> the version I'm thinking of upgrading.
>
> But note that THIS upward compatibility bug has been declared to not be a 
> bug.  Will any others receive the same stamp?
>
> So please put on your engineer hat, and stop talking about "specious  
> claims" and hurting feelings.

My engineer hat _is_ on. Here is the logic that led to my use of the
phrase "specious claims":

  - you are claiming that there are backwards incompatibility changes
    lurking in git (or at least that is what I believe you to mean)

  - there has been _one_ such problem, and the person responsible for
    vetting such changes has solicited suggestions for doing better in
    the future. I don't think that is indicative of a pattern of such
    changes.

  - But let's say you have lost some faith in the git development
    process due to _this_ bug. But let's look at the history of this
    bug. It has been discussed several times for the past 2 years, along
    with a mention in the release notes several versions ago. It was not
    a surprise to anybody who has been developing git.

    So yes, maybe there _are_ other bugs just like it lurking. But
    wouldn't it stand to reason that those bugs have _also_ been
    discussed and mentioned in the release notes, or that the developers
    would know about them?

    In other words, I can see you losing enough faith to say "wow, the
    git developers don't communicate very well and I need to vet their
    changes and notes more carefully". I don't think it is reasonable to
    say that there are likely to be other, totally unknown backwards
    incompatible changes.

So

  1. I find your claim that such bugs exist to have little evidence to
     back it up.

  2. As an engineer, I have seen evidence of one problem (insufficient
     communication) but not of another (introduction of
     incompatibilities without on-list discussion). So I would choose to
     focus my resources on fixing the problem I have seen.

> Heck, I even got Linus himself to ask if us people were on drugs, and
> I didn't take it personally.  At least I'm saying something that can
> be disputed, and not ad hominem like Linus.  8)

Sorry, but I'm not impressed by your getting Linus to yell at you. It's
like shooting fish in a barrel. :)

> How to better notify them is to do it on a major release, like Git 2.0.  
> THEN, they expect upward compatibility to break.

Now that _is_ a reasonable suggestion. This change _did_ wait until the
jump to 1.6.0, which we thought of as a major version jump (just as 1.4
to 1.5 introduced a few minor but documented changes). I don't think
there is a plan for "git 2.0" short of serious incompatibilities in the
repo format (i.e., you can't use 2.x tools on 1.x repos and vice versa).
So perhaps our numbering should be more emphatic.

-Peff

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Perry Wagle]

On Aug 28, 2008, at 2:59 PM, Jeff King wrote:

>> I now have to TEST to find those crazy backwards-incompatibility bugs
>> before I can upgrade us to 1.6.0.  To test, I have to try to  
>> imagine what
>> I and others were assuming about git.  And this episode means that  
>> I can't
>> make any assumptions about the sanity of any changes since March,  
>> which is
>> the version I'm thinking of upgrading.
>>
>> But note that THIS upward compatibility bug has been declared to  
>> not be a
>> bug.  Will any others receive the same stamp?
>>
>> So please put on your engineer hat, and stop talking about "specious
>> claims" and hurting feelings.
>
> My engineer hat _is_ on. Here is the logic that led to my use of the
> phrase "specious claims":

Cool.  Thanks!  (seriously)

>  - you are claiming that there are backwards incompatibility changes
>    lurking in git (or at least that is what I believe you to mean)

I'm saying that I don't know and will have to do complete exhaustive  
testing to be sure (my faith in git has been severely shaken).  I  
already tested every step for months, and to do it "right", I have to  
do that all over again.  I don't have the time, so I have to do severe  
approximations.  One of the fixes is to see if I can get people to  
stop making frivolous changes: "ooo!  we have to rename everything in  
the API because lists, I mean hashtables, with 143 entries in them are  
offensive!".  If there was more reasoning than that, it was not  
displayed in this thread.


>  - there has been _one_ such problem, and the person responsible for
>    vetting such changes has solicited suggestions for doing better in
>    the future. I don't think that is indicative of a pattern of such
>    changes.

Ok.  My suggestion is that it shouldn't have been done in the first  
place, and we should now revert.  But others are saying over and over  
"its done!  live with it!".  I came in late.  What did I miss in the  
last 6 months.  Sounds like people have lots of practice with these  
water-over-the-dam's, surely this isn't the first time?

>  - But let's say you have lost some faith in the git development
>    process due to _this_ bug. But let's look at the history of this
>    bug. It has been discussed several times for the past 2 years,  
> along
>    with a mention in the release notes several versions ago. It was  
> not
>    a surprise to anybody who has been developing git.

In March 2008, the sample git-hooks and git-web used git<DASH>  
commands.  That was the last I looked at git until Tuesday of this week.

>    So yes, maybe there _are_ other bugs just like it lurking. But
>    wouldn't it stand to reason that those bugs have _also_ been
>    discussed and mentioned in the release notes, or that the  
> developers
>    would know about them?

This is declared to not be a bug, even though it breaks existing  
scripts, even those published in the main branch of git itself.

>    In other words, I can see you losing enough faith to say "wow, the
>    git developers don't communicate very well and I need to vet their
>    changes and notes more carefully". I don't think it is reasonable  
> to
>    say that there are likely to be other, totally unknown backwards
>    incompatible changes.

I'm going by the reasoning shown in this thread.  Why not?  I'm  
looking for a way not to have to do exhaustive testing on those  
scripts, so would love to hear it.

> So
>
>  1. I find your claim that such bugs exist to have little evidence to
>     back it up.

Induction.  If it happened once, it probably happened more than once.   
This wasn't a show stopper problem.  It wasn't broke, but it was  
"fixed" anyway.

>  2. As an engineer, I have seen evidence of one problem (insufficient
>     communication) but not of another (introduction of
>     incompatibilities without on-list discussion). So I would choose  
> to
>     focus my resources on fixing the problem I have seen.

I don't know what I missed, and am not sure how to search for in in  
ten thousand messages or so since March.  My style is to anticipate  
problems.

But I'll figure it out.  Part of that figure out process is posting to  
this thread.

>> Heck, I even got Linus himself to ask if us people were on drugs, and
>> I didn't take it personally.  At least I'm saying something that can
>> be disputed, and not ad hominem like Linus.  8)
>
> Sorry, but I'm not impressed by your getting Linus to yell at you.  
> It's
> like shooting fish in a barrel. :)

Yeah, well, that was supposed to be both a joke and to indicate that  
I'm not sitting here with steam coming out my ears.

Linus has his solution, that doesn't work for me.  He hasn't listened  
to my several attempts to say why, and he's mad because he thinks I'm  
not listening.  But I expect he's a busy guy with 10,000 emails a day  
to respond to, so them's the breaks.

>> How to better notify them is to do it on a major release, like Git  
>> 2.0.
>> THEN, they expect upward compatibility to break.
>
> Now that _is_ a reasonable suggestion. This change _did_ wait until  
> the
> jump to 1.6.0, which we thought of as a major version jump (just as  
> 1.4
> to 1.5 introduced a few minor but documented changes). I don't think
> there is a plan for "git 2.0" short of serious incompatibilities in  
> the
> repo format (i.e., you can't use 2.x tools on 1.x repos and vice  
> versa).
> So perhaps our numbering should be more emphatic.

I think I hear you.  Since git is young, I should expect  
incompatibilities with minor version changes, and not demand that they  
be held off for major version changes.  That seems very plausible.

But I think I'll still remain wary because 1.6 introduced a nearly  
complete renaming of the API for what, in this thread anyway,  
completely silly reasons.  If there are good reasons, I haven't seen  
them.

-- Perry

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jakub Narebski]

Perry Wagle <wagle@cs.indiana.edu> writes:

> On Aug 28, 2008, at 9:37 AM, Linus Torvalds wrote: 
>> On Thu, 28 Aug 2008, Felipe Contreras wrote:
>>>
>>> If the git-foo was supposed to be deprecated in 1.6.0
>>
>> Itw as deprecated over a _year_ ago.
> 
> No, it wasn't.  As of March 2008, git<DASH> was still in the sample
> hooks and in git-web. [...]

If by "git-web" you mean "gitweb", the git web interface in Perl, this
is simply not true.  From the commit 25691fb (gitweb: Use --git-dir
parameter instead of setting $ENV{'GIT_DIR'}) _at least_ gitweb uses
"git <comd>" and not "git-cmd" form.  And this commit was on 28 August
2006, so in March 2008 gitweb didn't use git<DASH> form...

Check your facts, please...

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jeff King]

On Thu, Aug 28, 2008 at 03:33:26PM -0700, Perry Wagle wrote:

> Ok.  My suggestion is that it shouldn't have been done in the first  
> place, and we should now revert.  But others are saying over and over  
> "its done!  live with it!".  I came in late.  What did I miss in the last 
> 6 months.  Sounds like people have lots of practice with these  
> water-over-the-dam's, surely this isn't the first time?

No, it really is the first time.

> In March 2008, the sample git-hooks and git-web used git<DASH> commands.  
> That was the last I looked at git until Tuesday of this week.

Yes, and some of the test scripts still have git-* in them. I think in
that respect, the git community has been very bad about eating our own
dog food.

>>    So yes, maybe there _are_ other bugs just like it lurking. But
>>    wouldn't it stand to reason that those bugs have _also_ been
>>    discussed and mentioned in the release notes, or that the developers
>>    would know about them?
>
> This is declared to not be a bug, even though it breaks existing scripts, 
> even those published in the main branch of git itself.

I think the bug is not in the change, but in the deprecation process and
communication. But I think the definition of "bug" is vague enough to
simply be in the eye of the beholder.

> I'm going by the reasoning shown in this thread.  Why not?  I'm looking 
> for a way not to have to do exhaustive testing on those scripts, so would 
> love to hear it.

Ultimately you must be the judge of what and how much to test on your
systems. But if you are asking if there are other similar compatibility
bugs in 1.6.0, then my opinion, as somebody who follows the git list
quite closely and contributes some code, is that no, there are not.

>>  1. I find your claim that such bugs exist to have little evidence to
>>     back it up.
>
> Induction.  If it happened once, it probably happened more than once.   
> This wasn't a show stopper problem.  It wasn't broke, but it was "fixed" 
> anyway.

Induction in this manner is not a very rigorous argument (we're being
engineers, right?). I gave several reasons already why the probability
is low that another such bug exists, mostly related to the lack of
indicators.

> I don't know what I missed, and am not sure how to search for in in ten 
> thousand messages or so since March.  My style is to anticipate problems.

Sure, I wouldn't want to go back and read all of the messages either.
But this was mentioned in the release notes, too. Why don't you start
with them?

> I think I hear you.  Since git is young, I should expect  
> incompatibilities with minor version changes, and not demand that they be 
> held off for major version changes.  That seems very plausible.

That isn't quite what I meant. What I meant was that our idea of a major
version number is the middle number. That is, the time to introduce a
few minor incompatibilities is when that number jumps (but they should
be documented for a significant time period ahead of time, which this
was).  I don't expect to jump to "git 2.0" basically ever. Just as I
don't really expect Linux 3.0 anytime soon. But I, of course, am not in
charge of such things, so you may take that with a grain of salt.

> But I think I'll still remain wary because 1.6 introduced a nearly  
> complete renaming of the API for what, in this thread anyway, completely 
> silly reasons.  If there are good reasons, I haven't seen them.

I think the reasons have been mentioned a few times. Maybe you just
didn't think they were good.

-Peff

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Perry Wagle]

Jeff King has convinced me that it's perfectly legitimate to introduce  
non-upward compatibilities in minor version releases of "young"  
software.

My introduction to the problem was Tuesday of this week and this  
thread.  The reasoning that I generally saw in this thread was insane,  
and it scared me.  With some of the feedback I received, I now see a  
bigger picture where these decisions aren't so willy-nilly.

I think the lesson here, however, it that the correct way to have done  
this is to first remove all the git<DASH>'s from the source, demos,  
sample, documentation, etc.  Second, BIG PAUSE (full minor version  
release cycle?) Then, third, get rid of git<DASH> in <prefix>/bin.

The doctor expects my full recovery tomorrow.  8)

Thanks!

-- Perry

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Perry Wagle]

I did:

pwagle@starscream:/usr/lib/cgi-bin$ ls -l
total 352
-rw-r--r-- 1 root root    164 2008-03-07 12:03 git-favicon.png
-rw-r--r-- 1 root root    208 2008-03-07 12:03 git-logo.png
-rwxr-xr-x 1 root root 167729 2008-03-07 12:03 gitweb.cgi
-rw-r--r-- 1 root root   7112 2008-03-07 12:03 gitweb.css
-rwxr-xr-x 1 root root 167932 2008-03-07 12:03 gitweb.perl
pwagle@starscream:/usr/lib/cgi-bin$ grep git- * | wc -l
68
pwagle@starscream:/usr/lib/cgi-bin$

On Aug 28, 2008, at 4:03 PM, Jakub Narebski wrote:

> Perry Wagle <wagle@cs.indiana.edu> writes:
>
>> On Aug 28, 2008, at 9:37 AM, Linus Torvalds wrote:
>>> On Thu, 28 Aug 2008, Felipe Contreras wrote:
>>>>
>>>> If the git-foo was supposed to be deprecated in 1.6.0
>>>
>>> Itw as deprecated over a _year_ ago.
>>
>> No, it wasn't.  As of March 2008, git<DASH> was still in the sample
>> hooks and in git-web. [...]
>
> If by "git-web" you mean "gitweb", the git web interface in Perl, this
> is simply not true.  From the commit 25691fb (gitweb: Use --git-dir
> parameter instead of setting $ENV{'GIT_DIR'}) _at least_ gitweb uses
> "git <comd>" and not "git-cmd" form.  And this commit was on 28 August
> 2006, so in March 2008 gitweb didn't use git<DASH> form...
>
> Check your facts, please...
>
> -- 
> Jakub Narebski
> Poland
> ShadeHawk on #git
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Perry Wagle]

On Aug 28, 2008, at 4:04 PM, Jeff King wrote:

> On Thu, Aug 28, 2008 at 03:33:26PM -0700, Perry Wagle wrote:
>
>> But I think I'll still remain wary because 1.6 introduced a nearly
>> complete renaming of the API for what, in this thread anyway,  
>> completely
>> silly reasons.  If there are good reasons, I haven't seen them.
>
> I think the reasons have been mentioned a few times. Maybe you just
> didn't think they were good.

What I saw was "git<DASH><SPACE> produces a list of 143 commands.   
Long lists are inefficient.  Get rid of it!".  Actually the list is a  
hash table in any reasonable shell.  So its only aesthetics?

Being able to quickly see the list is very useful.  That could be done  
with git<SPACE><TAB>, except some people want that to be lobotomized  
to show only a fraction of the total.  My mind boggles at that one.

But see my other post.  I'm over it.

-- Perry

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

>> In March 2008, the sample git-hooks and git-web used git<DASH> commands.  
>> That was the last I looked at git until Tuesday of this week.
>
> Yes, and some of the test scripts still have git-* in them. I think in
> that respect, the git community has been very bad about eating our own
> dog food.

Not at all.

For one thing, hooks do run under modified PATH, as already pointed out in
the earlier thread.

Test scripts are executed in a special environment whose GIT_EXEC_PATH
points at the top of the build tree, where all git-foo lives.

Before anybody greps in Documentation/ to make pointless noises about some
dashed-form git-foo in there when we do not talk about what the user types
but about a command as a concept in manual pages, they are left in dashed
form deliberately, partly to help manpage browsers crosslink across pages.

We could have described typographic convention,

Cf.

    http://thread.gmane.org/gmane.comp.version-control.git/86940/focus=87008

but we ended up not doing so.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Perry Wagle]

My (ahem) implied point (sorry) also was that these "hook" scripts act  
as examples of how to write git scripts in general, and some of them  
are written to me run as regular scripts.

-- Perry

On Aug 28, 2008, at 4:24 PM, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
>
>>> In March 2008, the sample git-hooks and git-web used git<DASH>  
>>> commands.
>>> That was the last I looked at git until Tuesday of this week.
>>
>> Yes, and some of the test scripts still have git-* in them. I think  
>> in
>> that respect, the git community has been very bad about eating our  
>> own
>> dog food.
>
> Not at all.
>
> For one thing, hooks do run under modified PATH, as already pointed  
> out in
> the earlier thread.
>
> Test scripts are executed in a special environment whose GIT_EXEC_PATH
> points at the top of the build tree, where all git-foo lives.
>
> Before anybody greps in Documentation/ to make pointless noises  
> about some
> dashed-form git-foo in there when we do not talk about what the user  
> types
> but about a command as a concept in manual pages, they are left in  
> dashed
> form deliberately, partly to help manpage browsers crosslink across  
> pages.
>
> We could have described typographic convention,
>
> Cf.
>
>    http://thread.gmane.org/gmane.comp.version-control.git/86940/focus=87008
>
> but we ended up not doing so.

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Petr Baudis]

On Thu, Aug 28, 2008 at 04:24:50PM -0700, Junio C Hamano wrote:
> Before anybody greps in Documentation/ to make pointless noises about some
> dashed-form git-foo in there when we do not talk about what the user types
> but about a command as a concept in manual pages, they are left in dashed
> form deliberately, partly to help manpage browsers crosslink across pages.

What is the other part? And is it really worth the confusion? Are the
gazillions cases of dashed-form git-foo in there where we DO talk about
what the user types "pointless noises" too?

(I have argued further in the other mail but somehow we seem to have
gone off the list with that subthread, hmm.)

				Petr "Pasky" Baudis

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jakub Narebski]

Perry Wagle <wagle@cs.indiana.edu> writes:

> On Aug 28, 2008, at 2:59 PM, Jeff King wrote:
> 
>>> I now have to TEST to find those crazy backwards-incompatibility
>>> bugs before I can upgrade us to 1.6.0.  To test, I have to try to
>>> imagine what I and others were assuming about git.  And this
>>> episode means that I can't make any assumptions about the sanity
>>> of any changes since March, which is the version I'm thinking of
>>> upgrading.
>>>
>>> But note that THIS upward compatibility bug has been declared to
>>> not be a bug.  Will any others receive the same stamp?
>>>
>>> So please put on your engineer hat, and stop talking about "specious
>>> claims" and hurting feelings.

>>  - there has been _one_ such problem, and the person responsible for
>>    vetting such changes has solicited suggestions for doing better in
>>    the future. I don't think that is indicative of a pattern of such
>>    changes.
> 
> Ok.  My suggestion is that it shouldn't have been done in the first
> place, and we should now revert.  But others are saying over and over
> "its done!  live with it!".  I came in late.  What did I miss in the
> last 6 months.  Sounds like people have lots of practice with these
> water-over-the-dam's, surely this isn't the first time?

Errr... what last 6 months? Using "git <cmd>" over "git-<cmd>"
(also in scripts) was recommended for a long, long time' much more
than those 6 months.

Besides, the question stated in this thread was not whether to move
"git-*" commands outside $(bindir) (usually '/usr/bin'), but whether
to not create or not links (or symlinks, or hardcopy) in gitexecdir.
 
>>  - But let's say you have lost some faith in the git development
>>    process due to _this_ bug. But let's look at the history of this
>>    bug. It has been discussed several times for the past 2 years, along
>>    with a mention in the release notes several versions ago. It was not
>>    a surprise to anybody who has been developing git.
> 
> In March 2008, the sample git-hooks and git-web used git<DASH>
> commands.  That was the last I looked at git until Tuesday of this
> week.

As I said earlier in this thread, if by git-web you mean gitweb this
is simply not true.  _At least_ since commit 25691fb (gitweb: Use
--git-dir parameter instead of setting $ENV{'GIT_DIR'}) gitweb used
dashless form.

> But I think I'll still remain wary because 1.6 introduced a nearly
> complete renaming of the API for what, in this thread anyway,
> completely silly reasons.  If there are good reasons, I haven't seen
> them.

IIRC the reasons are git wrapper options linke --paginate or
--git-dir, equal treatment of git aliases, and cluttering of bindir
(which might be ~/bin).

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jeff King]

[dropping cc's because I think most people don't care about this bit]

On Thu, Aug 28, 2008 at 04:22:12PM -0700, Perry Wagle wrote:

> What I saw was "git<DASH><SPACE> produces a list of 143 commands.  Long 
> lists are inefficient.  Get rid of it!".  Actually the list is a hash 
> table in any reasonable shell.  So its only aesthetics?

I saw some talk of efficiency, but it was mainly "100,000 files in one
directory makes your filesystem performance suck". But maybe somebody
talked about the shell. I think there is "143 is too many, and scares
new users". And I think there is "systems with hardlink problems ended
up with 100+ copies of the git binary, which is big". For the latter,
you could still keep git-* with a much smaller wrapper, of course.

> Being able to quickly see the list is very useful.  That could be done  
> with git<SPACE><TAB>, except some people want that to be lobotomized to 
> show only a fraction of the total.  My mind boggles at that one.

I think there is a recognition that some of the commands aren't really
that useful to end users, but are kept around as helpers or as scripts.
For example, the interactive mode of "git add" is implemented in perl
(while the rest is implemented in C). So it is purely an implementation
issue that the script git-add--interactive exists. Nobody should be
calling it directly, but rather going through "git add -i", which will
call it as necessary with the right command line options.

> But see my other post.  I'm over it.

Good. :)

-Peff

git-* in test scripts (was On deprecating "git-foo" for builtins)

[Jeff King]

On Thu, Aug 28, 2008 at 04:24:50PM -0700, Junio C Hamano wrote:

> Test scripts are executed in a special environment whose GIT_EXEC_PATH
> points at the top of the build tree, where all git-foo lives.

I am not sure how GIT_EXEC_PATH is relevant. We put the git top-level
directory in the PATH, which is why "git-foo" works at all in the test
scripts. But the install by default does _not_ put those commands in
the PATH. So the test scripts serve as a poor example of how to use
git. The commands contained within them would not run in an ordinary git
installation.

-Peff

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Jeff King]

On Thu, Aug 28, 2008 at 04:14:14PM -0700, Perry Wagle wrote:

> I did:
>
> pwagle@starscream:/usr/lib/cgi-bin$ ls -l
> total 352
> -rw-r--r-- 1 root root    164 2008-03-07 12:03 git-favicon.png
> -rw-r--r-- 1 root root    208 2008-03-07 12:03 git-logo.png
> -rwxr-xr-x 1 root root 167729 2008-03-07 12:03 gitweb.cgi
> -rw-r--r-- 1 root root   7112 2008-03-07 12:03 gitweb.css
> -rwxr-xr-x 1 root root 167932 2008-03-07 12:03 gitweb.perl
> pwagle@starscream:/usr/lib/cgi-bin$ grep git- * | wc -l
> 68
> pwagle@starscream:/usr/lib/cgi-bin$

1. Your numbers are doubled because gitweb.cgi is the built form of
gitweb.perl.

2. Look at the grep output. They are all in comments or messages.
Perhaps the messages should say "open git diff failed" instead of "open
git-diff failed". But the "git-foo" form has been kept as a
typographical convention because it makes more sense from a language
perspective (just as you would hyphenate some compound words, or an
adjective phrase). Perhaps that is a mistake, given the confusion.

-Peff

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Perry Wagle]

Okay, thanks for the analysis!  He pulled a minor remark out and said  
I didn't look, when I had.  I have other things to do this week, but  
this thread is now, so I gotta do the ballpark measurements now (with  
some hope of reversing a upward compatibility breakage, which isn't  
important any more, see my other post).  Later I go in and s/git<DASH>/ 
git<SPACE>/g in my one-true-editor 8) and see for sure how many I  
actually need to change.  Gitweb wasn't my main problem, just one I  
had to think about when I can sit down and test the upgrade to 1.6.0.

-- Perry


On Aug 28, 2008, at 4:45 PM, Jeff King wrote:

> On Thu, Aug 28, 2008 at 04:14:14PM -0700, Perry Wagle wrote:
>
>> I did:
>>
>> pwagle@starscream:/usr/lib/cgi-bin$ ls -l
>> total 352
>> -rw-r--r-- 1 root root    164 2008-03-07 12:03 git-favicon.png
>> -rw-r--r-- 1 root root    208 2008-03-07 12:03 git-logo.png
>> -rwxr-xr-x 1 root root 167729 2008-03-07 12:03 gitweb.cgi
>> -rw-r--r-- 1 root root   7112 2008-03-07 12:03 gitweb.css
>> -rwxr-xr-x 1 root root 167932 2008-03-07 12:03 gitweb.perl
>> pwagle@starscream:/usr/lib/cgi-bin$ grep git- * | wc -l
>> 68
>> pwagle@starscream:/usr/lib/cgi-bin$
>
> 1. Your numbers are doubled because gitweb.cgi is the built form of
> gitweb.perl.
>
> 2. Look at the grep output. They are all in comments or messages.
> Perhaps the messages should say "open git diff failed" instead of  
> "open
> git-diff failed". But the "git-foo" form has been kept as a
> typographical convention because it makes more sense from a language
> perspective (just as you would hyphenate some compound words, or an
> adjective phrase). Perhaps that is a mistake, given the confusion.
>
> -Peff

Re: git-* in test scripts

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Thu, Aug 28, 2008 at 04:24:50PM -0700, Junio C Hamano wrote:
>
>> Test scripts are executed in a special environment whose GIT_EXEC_PATH
>> points at the top of the build tree, where all git-foo lives.
>
> I am not sure how GIT_EXEC_PATH is relevant. We put the git top-level
> directory in the PATH, which is why "git-foo" works at all in the test
> scripts. But the install by default does _not_ put those commands in
> the PATH. So the test scripts serve as a poor example of how to use
> git. The commands contained within them would not run in an ordinary git
> installation.

Well, I was merely replying to your message.  If you admit that tests are
special and a poor example, why did you bring it up? ;-)

Re: git-* in test scripts

[Jeff King]

On Thu, Aug 28, 2008 at 05:04:46PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > On Thu, Aug 28, 2008 at 04:24:50PM -0700, Junio C Hamano wrote:
> >
> >> Test scripts are executed in a special environment whose GIT_EXEC_PATH
> >> points at the top of the build tree, where all git-foo lives.
> >
> > I am not sure how GIT_EXEC_PATH is relevant. We put the git top-level
> > directory in the PATH, which is why "git-foo" works at all in the test
> > scripts. But the install by default does _not_ put those commands in
> > the PATH. So the test scripts serve as a poor example of how to use
> > git. The commands contained within them would not run in an ordinary git
> > installation.
> 
> Well, I was merely replying to your message.  If you admit that tests are
> special and a poor example, why did you bring it up? ;-)

I don't quite follow you. I think that the tests are actively being used
by people to see how they should invoke git, but they are very bad for
that, because they are still using the dashed form. So either the people
should stop doing that, or the tests should stop using the dashed form.
I think the latter is much easier for us to control.

I sent a patch for this probably a year ago, but nobody seemed
interested. I'm sure it is hopelessly out of date at this point (it was
not as easy as a mechanical change because there are other things that
look like git-*, like filename arguments to commands).

-Peff

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Andreas Ericsson]

Jeff King wrote:
> On Thu, Aug 28, 2008 at 03:33:26PM -0700, Perry Wagle wrote:
> 
>> I'm going by the reasoning shown in this thread.  Why not?  I'm looking 
>> for a way not to have to do exhaustive testing on those scripts, so would 
>> love to hear it.
> 
> Ultimately you must be the judge of what and how much to test on your
> systems. But if you are asking if there are other similar compatibility
> bugs in 1.6.0, then my opinion, as somebody who follows the git list
> quite closely and contributes some code, is that no, there are not.
> 

There's one, actually. The default pack-index version is increased now,
so really, really old clients (pre-1.4.5) won't be able to understand
the packs generated by default by a new server. I haven't examined how
and when this affect clients, although I believe only those using an
ancient client that fetch pre-created packs over dumb transport (http
or rsync) repo packed with pack.indexversion = 2, or with 1.6.0
without a pack.indexversion setting at all, will suffer.

Encountering that particular scenario should be very rare indeed.

Apart from that, I agree with Jeff about there not being any problems
regarding compatibility, and I wholeheartedly agree with the hint to
start reading the releasenotes.

As for suggesting future improvements, perhaps relnotes entries with
the slightest chance of breaking anything for anyone could be marked
"COMPAT" or something, so Perry and the likes of him can find them
easily. I also agree with the suggestion that git itself should be
free of a deprecated way of doing things at the deprecation date.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Matthieu Moy]

Andreas Ericsson <ae@op5.se> writes:

> There's one, actually. The default pack-index version is increased now,
> so really, really old clients (pre-1.4.5) won't be able to understand
> the packs generated by default by a new server.

AAUI, the pack itself is sent over the network, but the index is
generated locally when receiving the pack, so this shouldn't be a
problem.

-- 
Matthieu

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Andreas Ericsson]

Matthieu Moy wrote:
> Andreas Ericsson <ae@op5.se> writes:
> 
>> There's one, actually. The default pack-index version is increased now,
>> so really, really old clients (pre-1.4.5) won't be able to understand
>> the packs generated by default by a new server.
> 
> AAUI, the pack itself is sent over the network, but the index is
> generated locally when receiving the pack, so this shouldn't be a
> problem.
> 

Which is why I later in the same message pointed out that this should
only happen when using dumb protocols where the pack isn't reindexed
after it has been fetched.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Matthias Kestenholz]

On Fri, Aug 29, 2008 at 10:05 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>> There's one, actually. The default pack-index version is increased now,
>> so really, really old clients (pre-1.4.5) won't be able to understand
>> the packs generated by default by a new server.
>
> AAUI, the pack itself is sent over the network, but the index is
> generated locally when receiving the pack, so this shouldn't be a
> problem.
>

If you use the git or ssh protocol, then yes. If you use dumb protocols such as
HTTP or rsync, no.

Matthias

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Matthieu Moy]

"Matthias Kestenholz" <mk@spinlock.ch> writes:

>> AAUI, the pack itself is sent over the network, but the index is
>> generated locally when receiving the pack, so this shouldn't be a
>> problem.
>
> If you use the git or ssh protocol, then yes. If you use dumb protocols such as
> HTTP or rsync, no.

Thanks for the clarification, and sorry for the noise then ;-).

-- 
Matthieu

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Wincent Colaiuta]

El 28/8/2008, a las 23:23, Jeff King escribió:

> I don't think Junio is declaring success. In fact, I think he has sent
> several messages saying (paraphrasing of course):
>
>  - this was obviously not done in the best manner possible, because of
>    the number of people complaining

One thing we mustn't lose sight of is that the number of people  
complaining is that it is utterly insignificant compared to the  
seething hordes that have complained about the number of git- commands  
in /usr/bin over the years. We're talking about a dozen or so compared  
to hundreds. And the change is likely to save us from hundreds more in  
the future.

Cheers,
Wincent

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Felipe Contreras]

On Thu, Aug 28, 2008 at 7:37 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Thu, 28 Aug 2008, Felipe Contreras wrote:
>>
>> If the git-foo was supposed to be deprecated in 1.6.0
>
> Itw as deprecated over a _year_ ago.
>
>> When it becomes truly obsolete, then people can rely on git exec-dir,
>> which will be disabled by default.
>
> It _is_ obsolete, but there's a trivial compatibility thing.
>
> Are you happy now? How hard is it to really understand?

It only takes one word; obsolete. I haven't heard that git-foo is
obsolete until now, all I heard is that it was deprecated. Maybe I
should have paid more attention but that's not the point.

What other projects do is make very visible when something is
deprecated, like a big, annoying, unbearable warning. Next time you
deprecated a command it might be a good idea to add the warning each
time the command is used, and obsolete it later on.

Also, if it's a big change like this git- stuff, then do a major version bump.

If you had marked 1.6 as 2.0, and added warnings when you deprecated
the git-foo stuff then the users would have no excuse. It would have
been obvious and this huge thread would have been avoided.

Personally I'm subscribed to the mailing and I read the release notes
of 1.6, but I didn't register that change. I install my git stuff to
/opt/git, so when I was using git-foo I was using the old commands
that come from Fedora. It wasn't until I read this thread that I
noticed.

Don't expect users to be a aware of what's happening on the project,
many wouldn't even notice that there was a minor version bump. Julio,
I guess that recommendation goes for you.

Best regards.

-- 
Felipe Contreras

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Aidan Van Dyk]

[-- Attachment #1: Type: text/plain, Size: 1987 bytes --]

* Perry Wagle <wagle@cs.indiana.edu> [080801 00:00]:
> Jeff King has convinced me that it's perfectly legitimate to introduce  
> non-upward compatibilities in minor version releases of "young"  
> software.

This is the gist of the problem.  You keep hammering about a
"non-upwards compatibilities in minor version releases", yet you have
*not* pointed out one such in-compatibility in a minor version release..

Remember, in git, 1.6 is a "major version" release, with release notes, etc.
1.5.X is a "minor version" release.
1.5.X.Y is a "patch" release.

It's a pretty normal versioning scheme.

Git 1.5.X -> Git 1.6.X is a major release upgrade.  And the Git 1.5
release notes have claimed for a while that git-<cmd> executibles are
going to be moved out of the default path for a while.  And the Git 1.6
release notes claimed they were...

*And* git developpers have admitted that communication about that
pending change was obviously insufficient...

But that's a hard problem...

How do developers make sure that users are reading release notes?
*Especially* in a world where software is packaged up by
systems/distros/etc.  It's a problem that hits software across the
board, linux kernel, PostgreSQL, glibc, gcc, X.org, HylaFAX, and yes,
git.

Git 1.5.4 has had the "git-exec-dir in path" deprecated for months.  How
can we do a better job of letting *users* know of the documented stuff
in the release notes?

Can you imagine the outcry if git was made to look for the config value
core.hasreadreleasenotes.<version> on every invocation, and if it wasn't
set, forced the releasenotes throught the pager?  That way, you woudl
have known 6 months ago that git had published release-notes saying that
git-exec-dir change was going to happen...

-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Felipe Contreras]

On Fri, Aug 29, 2008 at 6:24 PM, Aidan Van Dyk <aidan@highrise.ca> wrote:
> * Perry Wagle <wagle@cs.indiana.edu> [080801 00:00]:
>> Jeff King has convinced me that it's perfectly legitimate to introduce
>> non-upward compatibilities in minor version releases of "young"
>> software.
>
> This is the gist of the problem.  You keep hammering about a
> "non-upwards compatibilities in minor version releases", yet you have
> *not* pointed out one such in-compatibility in a minor version release..
>
> Remember, in git, 1.6 is a "major version" release, with release notes, etc.
> 1.5.X is a "minor version" release.
> 1.5.X.Y is a "patch" release.

What is X (2.0)?

-- 
Felipe Contreras

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Aidan Van Dyk]

[-- Attachment #1: Type: text/plain, Size: 1195 bytes --]

* Felipe Contreras <felipe.contreras@gmail.com> [080829 12:11]:
> On Fri, Aug 29, 2008 at 6:24 PM, Aidan Van Dyk <aidan@highrise.ca> wrote:
> > * Perry Wagle <wagle@cs.indiana.edu> [080801 00:00]:
> >> Jeff King has convinced me that it's perfectly legitimate to introduce
> >> non-upward compatibilities in minor version releases of "young"
> >> software.
> >
> > This is the gist of the problem.  You keep hammering about a
> > "non-upwards compatibilities in minor version releases", yet you have
> > *not* pointed out one such in-compatibility in a minor version release..
> >
> > Remember, in git, 1.6 is a "major version" release, with release notes, etc.
> > 1.5.X is a "minor version" release.
> > 1.5.X.Y is a "patch" release.
> 
> What is X (2.0)?

X would be a digit, like 0, 1, 2, 3, 4, 5, 6, 7, 8, or 9, as in the git
1.5 releases:
	1.5.0
	1.5.1
	1.5.2
	1.5.3
	1.5.4
	1.5.4
	1.5.6

And now also:
	1.6.0, being the first of the 1.6 releases...

a.
-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Felipe Contreras]

On Fri, Aug 29, 2008 at 7:24 PM, Aidan Van Dyk <aidan@highrise.ca> wrote:
> * Felipe Contreras <felipe.contreras@gmail.com> [080829 12:11]:
>> On Fri, Aug 29, 2008 at 6:24 PM, Aidan Van Dyk <aidan@highrise.ca> wrote:
>> > * Perry Wagle <wagle@cs.indiana.edu> [080801 00:00]:
>> >> Jeff King has convinced me that it's perfectly legitimate to introduce
>> >> non-upward compatibilities in minor version releases of "young"
>> >> software.
>> >
>> > This is the gist of the problem.  You keep hammering about a
>> > "non-upwards compatibilities in minor version releases", yet you have
>> > *not* pointed out one such in-compatibility in a minor version release..
>> >
>> > Remember, in git, 1.6 is a "major version" release, with release notes, etc.
>> > 1.5.X is a "minor version" release.
>> > 1.5.X.Y is a "patch" release.
>>
>> What is X (2.0)?
>
> X would be a digit, like 0, 1, 2, 3, 4, 5, 6, 7, 8, or 9, as in the git
> 1.5 releases:
>        1.5.0
>        1.5.1
>        1.5.2
>        1.5.3
>        1.5.4
>        1.5.4
>        1.5.6
>
> And now also:
>        1.6.0, being the first of the 1.6 releases...

I meant 'X.0.0', if 1.X is major, what is X.0? Huge?

-- 
Felipe Contreras

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Aidan Van Dyk]

[-- Attachment #1: Type: text/plain, Size: 385 bytes --]

* Felipe Contreras <felipe.contreras@gmail.com> [080829 12:28]:
 
> I meant 'X.0.0', if 1.X is major, what is X.0? Huge?

Backwards compatible?

;-)

-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Andreas Ericsson]

Felipe Contreras wrote:
> On Fri, Aug 29, 2008 at 7:24 PM, Aidan Van Dyk <aidan@highrise.ca> wrote:
>> * Felipe Contreras <felipe.contreras@gmail.com> [080829 12:11]:
>>> On Fri, Aug 29, 2008 at 6:24 PM, Aidan Van Dyk <aidan@highrise.ca> wrote:
>>>> * Perry Wagle <wagle@cs.indiana.edu> [080801 00:00]:
>>>>> Jeff King has convinced me that it's perfectly legitimate to introduce
>>>>> non-upward compatibilities in minor version releases of "young"
>>>>> software.
>>>> This is the gist of the problem.  You keep hammering about a
>>>> "non-upwards compatibilities in minor version releases", yet you have
>>>> *not* pointed out one such in-compatibility in a minor version release..
>>>>
>>>> Remember, in git, 1.6 is a "major version" release, with release notes, etc.
>>>> 1.5.X is a "minor version" release.
>>>> 1.5.X.Y is a "patch" release.
>>> What is X (2.0)?
>> X would be a digit, like 0, 1, 2, 3, 4, 5, 6, 7, 8, or 9, as in the git
>> 1.5 releases:
>>        1.5.0
>>        1.5.1
>>        1.5.2
>>        1.5.3
>>        1.5.4
>>        1.5.4
>>        1.5.6
>>
>> And now also:
>>        1.6.0, being the first of the 1.6 releases...
> 
> I meant 'X.0.0', if 1.X is major, what is X.0? Huge?
> 

X.0 is "technically backwards incompatible".

If, for example, SHA1 turns out to be horribly broken, git might have
to be updated to use something else instead. Such a switch would
require a version bump from 1.x to 2.x.

That might come some day anyway, assuming we decide to make a flag-day
and just remove older-version compatibility code from git or some
such.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Steven Rostedt]

On Fri, 29 Aug 2008, Wincent Colaiuta wrote:

> El 28/8/2008, a las 23:23, Jeff King escribi?:
> 
> > I don't think Junio is declaring success. In fact, I think he has sent
> > several messages saying (paraphrasing of course):
> > 
> > - this was obviously not done in the best manner possible, because of
> >   the number of people complaining
> 
> One thing we mustn't lose sight of is that the number of people complaining is
> that it is utterly insignificant compared to the seething hordes that have
> complained about the number of git- commands in /usr/bin over the years. We're
> talking about a dozen or so compared to hundreds. And the change is likely to
> save us from hundreds more in the future.

I have to admit, the first time I saw the git-<tab> result, my first 
reaction was WTF!  But given time, I became use to it, and actually 
_preferred_ the dash version.

So I belonged to both camps. I complained about all the dash options, and 
I also complained about the dash options going away ;-)

Grant you, my complaints were not loud, I just utter some grumbles to git 
developers that I knew.

Lets not look at the number of complaints, but the level each complaint 
is. My first reaction to the git-<tab><tab> was more of a shock than 
anything else. So my complaint was very short lived, like someone cutting 
me off on the highway.

But after getting use to the dash version, and having that go away, makes 
me need to retrain myself to do things another way. This feels more like 
losing a pet, and complaining about that. This is a much more painful 
change than having to live with hordes of git commands.

-- Steve

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Teemu Likonen]

Steven Rostedt wrote (2008-08-30 09:24 -0400):

> But after getting use to the dash version, and having that go away,
> makes me need to retrain myself to do things another way. This feels
> more like losing a pet, and complaining about that. This is a much
> more painful change than having to live with hordes of git commands.

Don't worry, you didn't lose your pet. You have actually two pets now 
and it has become easier to play with both of them. Just shout

    PATH="$PATH:$(git --exec-path)"

and the older pet will come. However, it's preferred that you mostly 
show the new one to your neighbours.

:-)

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

[Steven Rostedt]

On Sat, 30 Aug 2008, Teemu Likonen wrote:

> Steven Rostedt wrote (2008-08-30 09:24 -0400):
> 
> > But after getting use to the dash version, and having that go away,
> > makes me need to retrain myself to do things another way. This feels
> > more like losing a pet, and complaining about that. This is a much
> > more painful change than having to live with hordes of git commands.
> 
> Don't worry, you didn't lose your pet. You have actually two pets now 
> and it has become easier to play with both of them. Just shout
> 
>     PATH="$PATH:$(git --exec-path)"
> 
> and the older pet will come. However, it's preferred that you mostly 
> show the new one to your neighbours.

Heh, yeah, I saw this. I was just letting people know that the number of 
complaints do not always measure the level people are complaining about.

The complaint I did about seeing the 140 git-* commands was more of a 
knee-jerk reaction, as suppose to the complaint about git-* going away, 
which would have been something that would affect me every time I hit '-'. 

Remember, before Linus stated that the 'git --exec-path' is not going to 
be deprecated, that was soon to disappear too.

-- Steve

Re: [PATCH] bash completion: Hide more plumbing commands

[Petr Baudis]

On Tue, Aug 26, 2008 at 10:38:45AM -0700, Jakub Narebski wrote:
> Petr Baudis <pasky@suse.cz> writes:
> > +		count-objects)    : plumbing;;
> 
> Plumbing (hyphenated name is a very good hint), but useful to decide
> when to repack. I'm partially to leaving it, as I use it from time to
> time from CLI.

Is this just residuum of customs developed before auto-gc was
introduced?

> > +		ls-files)         : plumbing;;
> 
> IIRC it doesn't have porcelain equivalent.

git status for the generally end-user-interesting functionality.

				Petr "Pasky" Baudis

Re: [PATCH] bash completion: Hide more plumbing commands

[Petr Baudis]

On Tue, Aug 26, 2008 at 11:25:35AM -0700, Junio C Hamano wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > Petr Baudis <pasky@suse.cz> wrote:
> >> git <tab><tab> still shows way too many commands, some of them
> >> are clearly plumbing. This patch hides the plumbing commands
> >> liberally (that is, in special cases, users still might want to
> >> call one of the hidden commands, a *normal* workflow should never
> >> involve these, though - and if it does, we have a UI problem anyway).
> >> 
> >> Signed-off-by: Petr Baudis <pasky@suse.cz>
> >
> > Acked-by: Shawn O. Pearce <spearce@spearce.org>
> >
> > Though I use git ls-remote at least once every other day to see
> > what branches are available on my egit/spearce.git fork.  Its ok,
> > I guess I can type a few extra characters...
> 
> Revision-requested-by: me
> 
> Unless/until we have an easy way to obtain the information "git-ls-files
> -u" gives during conflict resolution, ls-files should stay on the list of
> commonly used commands.

I started on a patch, but frankly, I hate it. Adding such a filtering to
git-status is quite invasive, while I believe that it's simply not worth
it - I have yet to encounter a situation with git when simply looking at
either git diff or plain git status is impractical to check which files
need to be merged yet, so I don't want to expend energy on a patch which
is going to be ugly and useless by my belief.

If you do insist that we need this functionality, can you please just
drop the git ls-files bit from the patch, or should I resend it?

Thanks,

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

Re: [PATCH] bash completion: Hide more plumbing commands

[Petr Baudis]

On Thu, Sep 04, 2008 at 12:23:50AM +0200, Petr Baudis wrote:
> I started on a patch, but frankly, I hate it. Adding such a filtering to
> git-status is quite invasive, while I believe that it's simply not worth
> it - I have yet to encounter a situation with git when simply looking at
> either git diff or plain git status is impractical to check which files
> need to be merged yet, so I don't want to expend energy on a patch which
> is going to be ugly and useless by my belief.
> 
> If you do insist that we need this functionality, can you please just
> drop the git ls-files bit from the patch, or should I resend it?

It just occured to me - what about

	git diff --diff-filter=U [--name-status]

or is that too long? (The universal answer being, "you can alias it".
;-)

				Petr "Pasky" Baudis

Re: [PATCH] bash completion: Hide more plumbing commands

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> On Tue, Aug 26, 2008 at 10:38:45AM -0700, Jakub Narebski wrote:
>> Petr Baudis <pasky@suse.cz> writes:
>> > +		count-objects)    : plumbing;;
>> 
>> Plumbing (hyphenated name is a very good hint), but useful to decide
>> when to repack. I'm partially to leaving it, as I use it from time to
>> time from CLI.
>
> Is this just residuum of customs developed before auto-gc was
> introduced?
>
>> > +		ls-files)         : plumbing;;
>> 
>> IIRC it doesn't have porcelain equivalent.
>
> git status for the generally end-user-interesting functionality.

I do not consider either of the above plumbing, but I tend to agree that
they are much less frequently used.  I think verify-pack falls into the
same category.

Applied to 'maint' but won't be pushing out for some time (my git day is
over).