[bug] git cannot find "git pull"?

> [jgarzik@viper linux-2.6]$ git pull
> git: 'pull' is not a git-command. See 'git --help'.
> 
> Did you mean this?
> 	shell

> I just upgraded to Fedora 11 (git-1.6.2.2-1.fc11.x86_64), and see
> the following:
>
>> [jgarzik@viper linux-2.6]$ git pull
>> git: 'pull' is not a git-command. See 'git --help'.
>>
>> Did you mean this?
>> 	shell
>
>
> Bleh...  :)  "git --help" indicates that "git pull" still exists.

> It is notable that Fedora 11 is the first Fedora release that follows
> the git 1.6.x defaults and installs most git binaries outside of PATH.
> I don't think that would cause this, and I haven't had any troubles
> running these packages for many months, but that's never stopped
> really obvious bugs in the past...

> Todd Zullinger <tmz@pobox.com> writes:
>
>> It is notable that Fedora 11 is the first Fedora release that
>> follows the git 1.6.x defaults and installs most git binaries
>> outside of PATH.  I don't think that would cause this, and I
>> haven't had any troubles running these packages for many months,
>> but that's never stopped really obvious bugs in the past...
>
> I do not follow distro packaged versions of git, but it may help to
> double check your spec changes against the output of
>
>     $ git log -p v1.5.6..v1.6.2.2 -- git.spec.in
>
> to see which paths need to be updated.

> Of course, you might not be using a specfile remotely similar to
> what we have in-tree (I believe it was originally done by Chris
> Wright who is listed as one of the persons who have something to do
> with Fedora packaged versions of git in your maintainers list), so
> this may not be a helpful tip at all, in which case I apologize...

> Chris has been busy with other things for a while.  I started helping
> with git package maintenance only in the last 6 months or so.  Over
> time, the spec file we have has drifted a bit from what is in git.git,
> though not terribly so.  I need to spend some time and look at what,
> if any, changes in the Fedora spec file would be good candidates for
> submitting to git.git.  I have been primarily concerned with making
> things work cleanly on Fedora and RHEL/CentOS though, so some of the
> changes may not be as generic as they ought to be if they are to be
> included in git.git.

> Todd Zullinger <tmz@pobox.com> writes:
> 
>> Chris has been busy with other things for a while.  I started helping
>> with git package maintenance only in the last 6 months or so.  Over
>> time, the spec file we have has drifted a bit from what is in git.git,
>> though not terribly so.  I need to spend some time and look at what,
>> if any, changes in the Fedora spec file would be good candidates for
>> submitting to git.git.  I have been primarily concerned with making
>> things work cleanly on Fedora and RHEL/CentOS though, so some of the
>> changes may not be as generic as they ought to be if they are to be
>> included in git.git.
> 
> I use the one in git.git only to cut the Fedora 9 packages for consumption
> by k.org people.  I do not know what their upgrade plans are, but last
> time they upgraded from FC 5 to Fedora 9 I had to scramble around and find
> an i386 box to produce binaries (the machine available to me at k.org is
> amd64).  Perhaps I should start preparing Fedora 11 environment now it is
> finally released, but before that I need to procure a new development box
> to host it in a vm, as the current box that is the primary integration
> machine for git and that hosts the Fedora 9 i386 vm has got too tight and
> I've been limping along; it does not have enough room to host another vm
> (and it is not even hardware vm capable)...

> Hi Jeff,
> 
> Jeff Garzik wrote:
>> I just upgraded to Fedora 11 (git-1.6.2.2-1.fc11.x86_64), and see
>> the following:
>>
>>> [jgarzik@viper linux-2.6]$ git pull
>>> git: 'pull' is not a git-command. See 'git --help'.
>>>
>>> Did you mean this?
>>> 	shell
>>
>> Bleh...  :)  "git --help" indicates that "git pull" still exists.
> 
> Yuck.  I can't reproduce this (and I would hope that if the Fedora
> packages have been broken for many weeks that someone would have
> noticed and complained loudly before the release...).  Of course, if
> there is something horribly wrong with the Fedora packages, I'll try
> to get it fixed as quickly as possible.
> 
> Do you happen to have any strange PATH set, other non-packaged git
> binaries installed, or funky aliases/settings in your git config?
> Does the problem occur after an upgrade or clean install?  For all
> users?

> No strange PATH settings, and this was a completely fresh 
> Fedora-11/x86-64 reformat and reinstall...
> 
> Adding "--exec-path=/usr/libexec/git-core" seems to work.
> 
> I wonder if it is looking for /usr/libexec64/git-core or something?

> Jeff Garzik wrote:
>> No strange PATH settings, and this was a completely fresh
>> Fedora-11/x86-64 reformat and reinstall...
>>
>> Adding "--exec-path=/usr/libexec/git-core" seems to work.
>>
>> I wonder if it is looking for /usr/libexec64/git-core or something?
>
> Same failure (with same workaround) on Fedora 11/i386, fresh
> install.

> Jeff Garzik wrote:
>> Jeff Garzik wrote:
>>> No strange PATH settings, and this was a completely fresh
>>> Fedora-11/x86-64 reformat and reinstall...
>>>
>>> Adding "--exec-path=/usr/libexec/git-core" seems to work.
>>>
>>> I wonder if it is looking for /usr/libexec64/git-core or something?
>> Same failure (with same workaround) on Fedora 11/i386, fresh
>> install.
> 
> Well hell.  I can't reproduce this.  I setup an F-11/x86_64 instance
> and had no troubles.  Similarly for i386 using the Live USB image.
> 
> Is it possible that some other package is screwing up the git search
> path?  Running strings on /usr/bin/git I find libexec/git-core, so I
> don't think it's trying libexec64, which doesn't exist in an Fedora
> release that I know of.
> 
> I'd be very curious if anyone else can reproduce this and what
> differences there are in the package list between my working system
> and your broken ones.

> FWIW, to reproduce my Fedora install, this is the setup I always use
> for my lab computers:
>
> * perform a fresh format + install, not an upgrade
> * uncheck 'office' category
> * check 'software development' category
> * do not select 'customize now', thus using Fedora's default package
> selection

> Jeff Garzik wrote:
>> FWIW, to reproduce my Fedora install, this is the setup I always use
>> for my lab computers:
>>
>> * perform a fresh format + install, not an upgrade
>> * uncheck 'office' category
>> * check 'software development' category
>> * do not select 'customize now', thus using Fedora's default package
>> selection
> 
> Stranger and stranger.  I followed the above steps with an F-11/x86
> network install and then ran:

> Given that /usr/local/bin/*git* has not existed on my systems for a
> long time, it appears that this is a new behavior, being a bit more
> strict in complaining about an invalid GIT_EXEC_PATH, rather than
> simply falling back to the internal compiled default
> (/usr/libexec/git-core).

> Jeff Garzik wrote:
>> Found it!  A forgotten package I created, a collective of shell
>> scripts, was setting GIT_EXEC_PATH=/usr/local/bin.
> 
> Phew.  I was worried I might have to start drinking much earlier than
> usual today. ;)
> 
>> Given that /usr/local/bin/*git* has not existed on my systems for a
>> long time, it appears that this is a new behavior, being a bit more
>> strict in complaining about an invalid GIT_EXEC_PATH, rather than
>> simply falling back to the internal compiled default
>> (/usr/libexec/git-core).
> 
> Without looking closely at the make files and build logic, is it
> perhaps something caused by the previous Fedora git-1.6.0.x packages
> passing gitexecdir=%{_bindir} to make, while the F-11 and newer
> packages do not set any gitexecdir?