From: Jeff King Date: Thu, 07 May 2020 17:27:13 GMT Subject: Re: [PATCH v12 3/7] receive-pack: add new proc-receive hook Message-ID: <20200507172713.GA3645853@coredump.intra.peff.net> In-Reply-To: On Thu, Apr 30, 2020 at 11:33:27PM +0800, Jiang Xin wrote: > Thanks to Peff for providing technical details of the architecture. I > understand that "receive-pack" of GitHub backend is not involved in > references update (executing the commands), so the "proc-receive" hook > won't be turned on for GitHub's architecture. While in our > architecture (inspired by "spokes" of GitHub), the proxy will deliver > not only packfile, but also commands to all three replicas. The proxy > will execute "receive-pack" on the replica with a special argument, so > the proxy can talk with "receive-pack" with an extended protocol. > After running pre-receive hook and release the packfile from > quarantine, the replica will stop and wait for the proxy to > coordinate. After creating a distributed lock, the proxy will tell all > the replicas continue to update the references. One problem we met is > the proc-receive and the post-receive hook must be executed once. We > can make the execution of the hooks idempotent, or let only one of the > replica run the hook. We choose the latter. OK, that makes more sense. We solve that by not updating the refs at all via receive-pack (which gives us flexibility to run our own hooks separately on just one replica, etc). > I agree that adding new capability (report-status-v2) is a better > solution, but I think the above extension is a bit wordy. We add > additional 18 characters for each "ok " status, and add > additional 32 characters for each "ng " status. Can we > extend it like this: > > ok > [optional key-value pairs] > ng > [optional key-value pairs] I doubt the number of bytes is all that important, but certainly I'm happy with this (and it looks like what you put into v14). -Peff