Re: [PATCH v3] set-head: no update without change and better output for --auto

[Junio C Hamano <gitster@pobox.com>]

"Bence Ferdinandy" <bence@ferdinandy.com> writes:

> On Mon Sep 16, 2024 at 20:36, Junio C Hamano <gitster@pobox.com> 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.