On Thu, Nov 04, 2021 at 06:40:22PM -0700, Junio C Hamano wrote: > Neeraj Singh <nksingh85@xxxxxxxxx> writes: > > > Is there some reason we shouldn't die if writing the ref fails? We are > > already accustomed to dying if fsyncing a packfile or the index fails. > > If we look at the surrounding code and the callers of the function, > this caller of fsync() is about to signal a failure to its callers > by returning an error(). The callers are prepared to see an error > and cope with it. > > Introducing die() to such a library-ish part of the code deep in the > callchain is not exactly a good change, especially when it is > obvious how we can avoid it. And here's a good concrete example that relies on it: when receive-pack is taking in a push, if the ref fails it should report that via the protocol back to the client, rather than just hanging up the connection. That leaves the client less confused, and gives it the opportunity to attempt and report status on other ref updates. -Peff
