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 <trast@xxxxxxxxxxx> wrote:
> Tamas Csabina <tcsabina@xxxxxxxxx> writes:
>
>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html