Re: slow process of post-receive script on a remote (samba) share

Hi Thomas,

Thanks for the reply.
The script is a bash script, just to mention.

Meanwhile I`ve figured it out that the sluggish post-receive execution
was due to a (mis)-configuration in the samba share where the remote
repository is hosted. These are:
oplocks = No
level2 oplocks = No

Removing these from the share`s section in the smb.conf solved the
issue, and the push process is taking up around 4 seconds, which I
think is reliable.


Now, do I have to worry about allowing oplocks on the remote
repository from the git point of view? Thinking about concurrent push
operations from different developers?


Tamas


On 13 June 2013 14:19, Thomas Rast [off-list ref] wrote:

Tamas Csabina [off-list ref] writes:

quoted

I am using Git bash from version 1.8.3.msysgit.0, on a Windows 7x64 PC.
I have an issue with executing git push if I have a post-receive
script configured.
The content of the script is not really important, as if I have a
script that contains only commented out lines (around 70 lines), my
git push command is delayed with around 5 seconds.


I`ve tested the script on another PC and it is working fine. No delay
at all. So there are some issues on my PC regarding how git processes
remote scripts.

I took a wireshark trace with 2 scenarios on my PC:

 1. just execute `cat <path_to_the_script>\post-receive` command in the git bash
 2. did a `real` git push

Results of the wireshark traces shows:

 1. Read AndX Request, FID: 0x228f, 1024 bytes at offset 0 (1024 bytes
at time, always)
 2. Read AndX Request, FID: 0x21c9, 1 byte at offset 0 (1 byte, always)

Conclusion:
git push command reads the post-receive script in 1 byte chunks, which
dramatically slows down the execution process.

git doesn't read the script; the interpreter does.  In the case of a
script, the interpreter is specified in the #! line at the top; in the
case of a binary executable, it is specified within the executable (and
for linux, is usually /lib/ld-linux.so.2).

Exactly the same should happen if you run the hook manually, so you can
try that to debug it.

Note also that Weird Things(tm) relating to SIGPIPE may happen if you
don't read your input.  Even if you are only fooling around for testing,
a post-receive hook must consume its input, e.g., by discarding it with
'cat >/dev/null'.

--
Thomas Rast
trast@{inf,student}.ethz.ch