Unable to run git commands in a non-interactive environment

[Anthony Newnam]

I am attempting to use msysgit with Hudson. The git plugin works
correctly, but it isn't going through an msysgit shell (I believe) and
just running git.cmd. If I try to run any git commands myself, the
hang indefinitely.

For example, `git clone a b` will create b, a .git that is 20KB, and
then hang forever with no output.

Has anyone experienced this, have suggestions on a way to debug this
(guess I need to find something like strace for Windows...), etc.?

Thanks

[Konstantin Khomoutov]

Are you attempting to clone using the SSH transport?
Then the ssh client might ask you to accept the target host's
fingerprint or provide a password.

[Anthony Newnam]

Yes, I am using SSH. If I run the same command from the same user
interactively, it works without any prompting. The host is in my
~/.ssh/known_hosts, and my public key is already in the server.

I suspect that you are correct about what it is doing, but I don't
know why it would do it. Would there be some reason for msysgit to not
see my key or known_hosts when it is run as a service?

[Konstantin Khomoutov]

Anthony Newnam wrote:
> > > I am attempting to use msysgit with Hudson. The git plugin works
> > > correctly, but it isn't going through an msysgit shell (I believe) and
> > > just running git.cmd. If I try to run any git commands myself, the
> > > hang indefinitely.

[...]

> > Are you attempting to clone using the SSH transport?
> > Then the ssh client might ask you to accept the target host's
> > fingerprint or provide a password.
>
> Yes, I am using SSH. If I run the same command from the same user
> interactively, it works without any prompting. The host is in my
> ~/.ssh/known_hosts, and my public key is already in the server.
>
> I suspect that you are correct about what it is doing, but I don't
> know why it would do it. Would there be some reason for msysgit to not
> see my key or known_hosts when it is run as a service?

The first thing to check is to ensure the git.cmd script sees the same
environment in both cases.
So you could temporarily hack it and add something like
@set >X:\some\place\dump.txt
at the beginning of it, run it manually, save the generated file then
run it from within hudson and save the generated file again, then
compare them using any diff tool.

Also msysgit can be traced to some extent using the GIT_TRACE env.
variable (set to 1).
So you could rename git.cmd to git.orig.cmd and create a temporary
git.cmd containing something like
@echo off
set GIT_TRACE=1
%~d0%~p0git.orig.cmd %* 2>&1 >X:\some\place\trace.txt

Then you could see at the trace generated by a failing non-interactive
run.

[Anthony Newnam]

I haven't been using git.cmd because I'm already inside of an msysgit
shell when these commands are being invoked. git.cmd fails to run in
the shell (as I think is expected).

I set GIT_TRACE:

+ export GIT_TRACE=1
+ GIT_TRACE=1
+ git fetch
trace: built-in: git 'fetch'
trace: run_command: 'ssh' '-p' '29418' 'gerrit.domain.tld' 'git-upload-
pack '\''/base'\'''
trace: run_command: 'rev-list' '--quiet' '--objects' '--stdin' '--not'
'--all'
(a little lag here)
trace: run_command: 'index-pack' '--stdin' '--fix-thin' '--keep=fetch-
pack 1416 on localhost' '--pack_header=2,199410'
trace: built-in: git 'index-pack' '--stdin' '--fix-thin' '--keep=fetch-
pack 1416 on localhost' '--pack_header=2,199410'

and then it hangs indefinitely (although without the trace, I've let
it run for hours).

[Konstantin Khomoutov]

Anthony Newnam wrote:
> > > > > I am attempting to use msysgit with Hudson. The git plugin works
> > > > > correctly, but it isn't going through an msysgit shell (I believe) and
> > > > > just running git.cmd. If I try to run any git commands myself, the
> > > > > hang indefinitely.
> > [...]
> > > > Are you attempting to clone using the SSH transport?
> > > > Then the ssh client might ask you to accept the target host's
> > > > fingerprint or provide a password.
> >
> > > Yes, I am using SSH. If I run the same command from the same user
> > > interactively, it works without any prompting. The host is in my
> > > ~/.ssh/known_hosts, and my public key is already in the server.
> >
> > > I suspect that you are correct about what it is doing, but I don't
> > > know why it would do it. Would there be some reason for msysgit to not
> > > see my key or known_hosts when it is run as a service?

[...]

> > Also msysgit can be traced to some extent using the GIT_TRACE env.
> > variable (set to 1).

[...]

> I set GIT_TRACE:
>
> + export GIT_TRACE=1
> + GIT_TRACE=1
> + git fetch
> trace: built-in: git 'fetch'
> trace: run_command: 'ssh' '-p' '29418' 'gerrit.domain.tld' 'git-upload-
> pack '\''/base'\'''
> trace: run_command: 'rev-list' '--quiet' '--objects' '--stdin' '--not'
> '--all'
> (a little lag here)
> trace: run_command: 'index-pack' '--stdin' '--fix-thin' '--keep=fetch-
> pack 1416 on localhost' '--pack_header=2,199410'
> trace: built-in: git 'index-pack' '--stdin' '--fix-thin' '--keep=fetch-
> pack 1416 on localhost' '--pack_header=2,199410'
>
> and then it hangs indefinitely (although without the trace, I've let
> it run for hours).

Unfortunately, this requires a Git expect (which I'm not) to
understand.

My stab at this follows nonetheless.

As I understand, git-index-pack is called on the stream of objects
(a "pack") sent by the git-upload-pack process running on the server
side,
and it's supposed to create an index file for this pack and quit.
Then the pack will be shoveled into the local object store.

So I can see two possibilities here:
1) For some reason, git-upload-pack on the remote side does not
complete
and hence git-index-pack --stdin waits forever for the end of its
stream.
2) You have hit some bug in Git/msysgit which makes the git-index-pack
process
to lock up (or enter an endless loop or whatever).

Hence now I'd check the status of the involved processes after git-
index-pack hangs.
If you have access to the server side, check if there's a git-upload-
pack process running/sleeping.
Check if the local SSH process has its TCP stream open (Process
Explorer or tcpview from Sysinternals would do). If possible, attach
to git-index-pack using windbg and get its stack trace -- supposedly
this could tell if it's blocked in a syscall reading from stdin or
not.

I hope someone more knowledgeable will suggest more ideas to try out.

[Konstantin Khomoutov]

On Dec 6, 7:08 pm, Anthony Newnam <anth...@bnovc.com> wrote:
[...]

> trace: built-in: git 'index-pack' '--stdin' '--fix-thin' '--keep=fetch-
> pack 1416 on localhost' '--pack_header=2,199410'
>
> and then it hangs indefinitely (although without the trace, I've let
> it run for hours).

Still, I don't have any idea about how can this depend on the
environment...