| Commit message (Collapse) | Author | Files | Lines |
|---|
|
The hooks handler in the main daemon didn't wait for the hook client to
write fully, and sometimes prematurely closes the connection, causing
the hook client's splice to return EPIPE (or SIGPIPE if the signal
handler wasn't installed).
To remedy this, we call shutdown(sock, SHUT_WR) in the client, so that
attempts to read on the server side return EOF. Then we can simply use
io.Copy(&buf, conn) on the server side to fetch all of the data into a
buffer.
|
|
Previously we accepted handler connections at hooks_handle and used a
mess of channels and concurrent maps to let receive_pack handle the
session. This doesn't work well because there are conditions where a
push occurs but the hook is not called, e.g. when the destination branch
is up to date. There is no reliable way of checking whether the
subprocess is going to call the hook or not; it's technically possible
to parse stderr but that interface is not guaranteed to be stable and
IIRC has changed in the past). So receive_pack would be waiting on the
channel to receive a hooks connection to handle but it'll never receive
one, causing a deadlock. This entire thing was overengineered and was
very prone to error.
Here we let receive_pack put the cookie into the map, then start and
wait for the subprocess to finish. When the hook actually runs and
connects to its UNIX domain socket, the handler would check its cookie
within the map. If the hook doesn't run, then nothing happens. The
git-receive-pack subprocess blocks the execution of the SSH handler,
and when git-receive-pack exists, the SSH handler (using a defer)
deletes the cookie from the map.
There may be caveats in signal handling or other cases that cause the
cookie to be deleted from the map prematurely.
|
|
As this always suggests a programming mistake, we do not check the type
assertion, causing it to panic if the types don't match.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
