Re: git svn errors out with git-cat-file "usage" message

[Michael J Gruber <git@drmicha.warpmail.net>]

Martin Langhoff venit, vidit, dixit 30.04.2009 09:18:
> On Wed, Apr 29, 2009 at 11:05 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> But I just re-read your original report, and there's some inconsistency:
>>
>> git-svn triggers cat-file's usage message which says "git-cat-file ...".
>> The dash indicates that it is a git cat-file before v1.6.0.1-13-g34baebc
>> (where the dash was removed), so it's definitely not the current maint
>> you think you are using.
>>
>> Do you have older ubuntu git packages installed in $PATH?
> 
> Bingo! Yes,
> 
> ~$ which git-cat-file
> /usr/bin/git-cat-file
> ~$ /usr/bin/git version
> git version 1.5.6.3
> 
> now that's really weird. git from ~/bin is using git-cat-file from
> /usr/bin instead of ~/libexec/git-core ... how is the libexec path set
> in the PATH during the execution of the script?
> 
> the funny thing is that Ubuntu wants to have git-core in place if
> you're rebuilding kernel packages. I don't need to rebuild my kernel
> anymore but I am sure this is an issue for others. What's the trick?
> Add the libexec/git-core to the PATH before /usr/bin? Should git
> internally append libexec/git-core earlier in the search path?
> 

I'm pretty sure that git will use the correct version, i.e. "git
cat-file -x" will give you the usage line for the recent version. Or
does "env|grep GIT" return anything which could misdirect git?

I think the question is more what git-svn does. It uses git's perl
bindings, and it may very well be the case that your current, locally
installed git uses the current git-svn which in turn picks up the wrong
Git.pm.

As far as I can see, the last explicit usage of "git-cat-file" (with
dash) was removed from git-svn.perl in v1.5.5.1-136-gffe256f which
equals v1.5.6-rc0~8^2~2 which should precede your older git, unless
Debian/Ubuntu did something funny. (Fedora followed the out-of-bin
decision for git-* only with a delay, e.g.) That's why I suspected a
perl path issue. But I'm not a perl guy, so I'm sorry I can't help
further than suggesting to uninstall the old git (deb version of
--no-deps) and check if that's helping.

Michael