Re: [PATCH 0/3] Fixing volatile HEAD in push.default = current

Ramkumar Ramachandra [off-list ref] writes:

Junio C Hamano wrote:

quoted

The patch may have been done by a wrong motivation, in that it does
not fundamentally "fix" the itch.  The particular "itch" is not
something we are going to promise to the end users, ever, anyway.

Just out of curiosity, is it possible to write a correct fix at all?

Is there anything to "fix" in the first place, you have to wonder.

Your "git push there HEAD:master" would roughly do the following:

    (1) read HEAD to learn what commit you are pushing;

    (2) contact the other side and find where there tips are;

    (3) send a packfile that should be enough for the other side to
        have complete history leading to the commit you read in (1);

    (4) tell the other side to update its 'master' to the commit you
        read in (1).

If you drop step (1) and replace "the commit you read in (1)" in
steps (3) and (4) with "the commit you see in HEAD at this point by
re-reading HEAD", then such a "git push" that races with something
else you do in your other terminal may break---you can cause it to
see different commits at steps (3) and (4), potentially getting the
other side out of sync (but the receiving end does an independent
connectivity check so your push will likely to be rejected).

And the fix to such a breakage is to structure the code like the
above four steps to make it race-free.

If I understand your example correctly, you are talking about a
quite different thing.  "git push there HEAD:master" racing with
your other terminal that changes the HEAD sees different HEAD
depending on the order:

    (a) if the other terminal changes the HEAD first, step (1) will
        see that updated HEAD; or

    (b) if the step (1) reads HEAD before you change it in the other
        terminal, it will see the original HEAD.

But that is very much to be expected, isn't it?  It sounds similar
to

    I have "largedir" I want to get rid of, but there is a directory
    I want to save, "largedir/precious", in it, so I do

        cp -R largedir/precious precious

    and then run 'rm -rf largedir' in another terminal in parallel.

Is there anything to fix?