"Bence Ferdinandy" <bence@xxxxxxxxxxxxxx> writes: > On Mon Sep 16, 2024 at 20:36, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > [snip] > >> - This is inherently racy, isn't it? We read the _current_ value. >> After we do so, but before we write _our_ value, another process >> may update it, so we'd end up overwriting the value they wrote. > > So I've been thinking my first patch need not be so ambitious. The current > behaviour is to indiscriminately overwrite remote/HEAD. So what if we dial this > back a bit, leave the indiscriminate overwrite in place (the added benefit of > that is pretty small anyway) and only improve the printed output, which was the > main goal anyway? Yes. You could ignore races and it does not degrade correctness of the end result (i.e., you will still get the same "oops, that is not what I wrote, but somebody else overwritten what I wrote" and vice versa). Your new messages that try to differenciate "we noticed you are writing the same so we refrained from doing anything" and "we wrote this new value" can racily incorrect the same way. In other words, the message may claim that we detected a no-op change from value A to new value A hence we didn't do anything, but after the detection somebody may have wrote another value B from sideways, so the last message that hit the end user's eyes may imply the resulting value ought to be A but it is not because somebody else silently changed it to B. If we did not skip writing using racy logic, we would have written value A and reported that we updated it to value A, but the other party who silently wrote B may do so after all that happens, and the end result the user would see is the same (i.e. we tell the user the last value we expect it to be is A, but the final value is B). So, as long as we can explain the behaviour to the end-user well, I do not care too deeply. My impression was that avoiding it by just taking advantage of the atomicity afforded by create_symref() looked like a low hanging fruit, but that can be done by somebody who are curious to see how involved such a change actually is and can be safely left as a #leftoverbit ;-). Thanks.
