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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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? ;-)

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

> 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 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... :/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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. [...]

> 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

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

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

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

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

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

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

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

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

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