'pull' appears to be a git command, but we were not able to execute it. Maybe git-pull is broken?

[CB]

Win7x64.

I have uninstalled and reinstalled Git-1.8.3-preview20130601.exe.

"C:\Program Files (x86)\Git\cmd" is in the PATH.

Here is output from PowerShell:

[I:\Work\bitbucket\PluralSight\proj1] >git pull

fatal: 'pull' appears to be a git command, but we were not

able to execute it. Maybe git-pull is broken?

[I:\Work\bitbucket\PluralSight\proj1] >git stat

# On branch work2

nothing to commit, working directory clean

[I:\Work\bitbucket\PluralSight\proj1] >git fetch

Password for 'https://us...@bitbucket.org':

[I:\Work\bitbucket\PluralSight\proj1] >git rebase

fatal: 'rebase' appears to be a git command, but we were not

able to execute it. Maybe git-rebase is broken?

[I:\Work\bitbucket\PluralSight\proj1] >

Git has been working w/o problem for several weeks.  Any insights would be greatly appreciated....

Thanks.

[CB]

More information:

It appears all the git commands implemented by .exe files work:
git-fetch.exe, git-merge.exe, git-push.exe, etc.

It appears all the commands implemented as scripts to not work:
Git\libexec\git-core\git-pull
Git\libexec\git-core\git-rebase
etc.
So, whatever git.exe is calling to run the libexec\git-core scripts appears to be farkled...
Any insights would be appreciated!

[CB]

More information:

- commands in the git-bash shell work as expected.

- in the git-bash shell, Git\bin\git.exe is called.

- Git\bin is where sh.exe lives...

- in PowerShel (or cmd, or tcc), Git\cmd\git.exe is called.

- even after adding Git\bin to the PATH (after Git\cmd), the scripts don't work.

Very frustrating... 

[Philip Oakley]

I think there has been a relatively recent change to one of the 'Git for Windows' packages in terms of how it is packaged.

 

The issue (as I understand it) is that [previously] on Windows, under the msys layer, each of the git-* commands are simply a complete copy of the 'git.exe' application with the start address pointing to the relevant sub-command (simplisticly stated). This was very wasteful of install space, so those "git-*.exe" copies were dropped from the package. Unfortunately some scripts still call the dashed "git-*" version of the command (i.e. they were never updated to the modern form).

 

I think there was a discussion on the main list with the last two months on the issue, but I'm not sure if it is resolved in favour of supporting a reasonably compact Git for Windows version.

 

I understand that the portable version is OK (IIUC).

 

Philip

--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
 
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msy...@googlegroups.com
To unsubscribe from this group, send email to
msysgit+u...@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
 
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3349 / Virus Database: 3204/6477 - Release Date: 07/09/13

[Philip Oakley]

Try http://thread.gmane.org/gmane.comp.version-control.msysgit/18632 and subsequent messages. Not sure if it came to a good conclusion.

[CB]

Thanks for the reply, it mostly makes sense w/r/t .exe vs scripts (although the discussion regarding the patches was hard to follow...)

However, I installed the same msysgit install package on my laptop, and it works as expected.

Fortunately, it appears that the portable version  (PortableGit-1.8.3-preview20130601.7z) works as desired when I add its \cmd dir to my path.

Appreciate the help, and hope the installed version for Windows gets sorted out...

[CB]

Hmmm....

I unzipped the portable version into the typical install dir: "C:\Program Files (x86)\Git", and got the same errors.

Unzipped into "C:\git2", and it worked as expected.

Perhaps the problem is with the spaces in the path?

(But why does it work on the other computer....?!)

[Johannes Schindelin]

Hi CB,

On Wed, 10 Jul 2013, CB wrote:

> More information:
> - commands in the git-bash shell work as expected.
> - in the git-bash shell, Git\bin\git.exe is called.
>
> - Git\bin is where sh.exe lives...
>
> - in PowerShel (or cmd, or tcc), Git\cmd\git.exe is called.
>
> - even after adding Git\bin to the PATH (after Git\cmd), the scripts don't
> work.

Try setting the environment variable GIT_TRACE=1.

Ciao,
Johannes

[Konstantin Khomoutov]

On Wed, 10 Jul 2013 15:05:02 -0700 (PDT)
CB <ccb...@gmail.com> wrote:

> Hmmm....
> I unzipped the portable version into the typical install dir: "C:
> \Program Files (x86)\Git", and got the same errors.
> Unzipped into "C:\git2", and it worked as expected.
> Perhaps the problem is with the spaces in the path?
>
> (But why does it work on the other computer....?!)

Instead of guessing -- did you try running the failing commands after
executing
set GIT_TRACE=1
in the shell?

For instance, one reason for them to fail might be your user's env.
variables (or something else) trumps whatever you set in the system's
env. variable PATH. Without tracing, we can only continue to do sheer
guesses.

You could also inspect the real value of your PATH env. variable by
executing
set PATH
in your shell.

[CB]

Thanks for the reply.

I hadn't seen your posts until this morning -- I'll try using GIT_TRACE.

I have been checking the PATH, confirming that git-bash was using "C:\Program Files (x86)\Git\bin\git.exe", while PowerShell was using "C:\Program Files (x86)\Git\cmd\git.exe".

[Johannes Schindelin]

Hi CB,

On Thu, 11 Jul 2013, CB wrote:

> I hadn't seen your posts until this morning -- I'll try using GIT_TRACE.
>
> I have been checking the PATH, confirming that git-bash was using
> "C:\Program Files (x86)\Git\bin\git.exe", while PowerShell was
> using "C:\Program Files (x86)\Git\cmd\git.exe".

That might be the crucial difference, and it could have to do with
quoting. The source can be found here:

https://github.com/msysgit/msysgit/blob/master/src/git-wrapper/git-wrapper.c

You can rebuild it using /src/git-wrapper/release.sh *iff* using msysGit
(I recommend the net installer, and make sure to insert a space into the
directory you are installing it into so you can reproduce easily).

Ciao,
Johannes

[CB]

> I have been checking the PATH, confirming that git-bash was using
> "C:\Program Files (x86)\Git\bin\git.exe", while PowerShell was
> using "C:\Program Files (x86)\Git\cmd\git.exe".

That might be the crucial difference, and it could have to do with
quoting. The source can be found here:

https://github.com/msysgit/msysgit/blob/master/src/git-wrapper/git-wrapper.c

You can rebuild it using /src/git-wrapper/release.sh *iff* using msysGit
(I recommend the net installer, and make sure to insert a space into the
directory you are installing it into so you can reproduce easily).

I installed msysgit in "C:\msys git", and modified git-wrapper to display 'exepath'.

I:\work\bitbucket\proj1 [work2]> 'C:\msys git\cmd\git-wrapper.exe' rebase master

git-wrapper

exepath: C:\msys git

Current branch work2 is up to date.

I:\work\bitbucket\proj1 [work2]>

It appears that the space in the dir name does not affect the execution of the rebase script.

[Johannes Schindelin]

Hi,

Okay. TBH I would have been surprised.

What about the full output of a failing run *after* GIT_TRACE has been set
to 1?

Ciao,
Johannes

[CB]

> Okay. TBH I would have been surprised. 

> 

> What about the full output of a failing run *after* GIT_TRACE has been set 

> to 1? 

> 

Fresh install of Git-1.8.3-preview20130601.exe.

[I:\Work\bitbucket\proj1]

10:18:58>which git.exe

git.exe is an external : C:\Program Files (x86)\Git\cmd\git.exe

[I:\Work\bitbucket\proj1]

10:19:11>set GIT_TRACE=1

[I:\Work\bitbucket\proj1]

10:19:17>git rebase master

trace: exec: 'git-rebase' 'master'

trace: run_command: 'git-rebase' 'master'

fatal: 'rebase' appears to be a git command, but we were not

able to execute it. Maybe git-rebase is broken?

[I:\Work\bitbucket\proj1]

10:19:22>

[CB]

This is interesting -- using the portable version (PortableGit-1.8.3-preview20130601.7z):

[I:\Work\bitbucket\proj1]

10:31:02>c:\bin\git2-portable\cmd\git.exe rebase master

trace: exec: 'git-rebase' 'master'

trace: run_command: 'git-rebase' 'master'

trace: built-in: git 'rev-parse' '--parseopt' '--' 'master'

trace: built-in: git 'rev-parse' '--git-dir'

trace: built-in: git 'rev-parse' '--is-bare-repository'

trace: built-in: git 'rev-parse' '--show-toplevel'

trace: built-in: git 'config' '--bool' 'rebase.stat'

trace: built-in: git 'config' '--bool' 'rebase.autosquash'

trace: built-in: git 'rev-parse' '--verify' 'master^0'

trace: built-in: git 'rev-parse' '--verify' 'master^0'

trace: built-in: git 'symbolic-ref' '-q' 'HEAD'

trace: built-in: git 'rev-parse' '--verify' 'HEAD'

trace: built-in: git 'rev-parse' '--verify' 'HEAD'

trace: built-in: git 'update-index' '-q' '--ignore-submodules' '--refresh'

trace: built-in: git 'diff-files' '--quiet' '--ignore-submodules'

trace: built-in: git 'diff-index' '--cached' '--quiet' '--ignore-submodules' 'HEAD' '--'

trace: built-in: git 'merge-base' '46c5d5dbd94e7c75ebc09394d89ee5466780bcfe' '46c5d5dbd94e7c75ebc0

9394d89ee5466780bcfe'

trace: built-in: git 'rev-list' '--parents' '46c5d5dbd94e7c75ebc09394d89ee5466780bcfe..46c5d5dbd94

e7c75ebc09394d89ee5466780bcfe'

trace: exec: 'git-sh-i18n--envsubst' '--variables' 'Current branch $branch_name is up to date.'

trace: run_command: 'git-sh-i18n--envsubst' '--variables' 'Current branch $branch_name is up to da

te.'

trace: exec: 'git-sh-i18n--envsubst' 'Current branch $branch_name is up to date.'

trace: run_command: 'git-sh-i18n--envsubst' 'Current branch $branch_name is up to date.'

Current branch work2 is up to date.

[I:\Work\bitbucket\proj1]

10:31:11>