Patrick Steinhardt <ps@xxxxxx> writes: > Similar to `git push --atomic`, this commit thus introduces atomic > fetches. Instead of allocating one reference transaction per updated > reference, it causes us to only allocate a single transaction and commit > it as soon as all updates were received. If locking of any reference > fails, then we abort the complete transaction and don't update any > reference, which gives us an all-or-nothing fetch. > > Note that this may not completely fix the first of above downsides, as > the consistent view also depends on the server-side. If the server > doesn't have a consistent view of its own references during the > reference negotiation phase, then the client would get the same > inconsistent view the server has. This is a separate problem though and, > if it actually exists, can be fixed at a later point. With the help of the previous step, it is trivial to see that the single transaction around store_updated_refs() would be sufficient to achieve the atomicity. But what about FETCH_HEAD? Do we refrain from writing and/or appending to it when there is any failure? Thanks.
