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

From: Junio C Hamano <gitster@pobox.com>
Date: May 22, 2013, 17:11 UTC
Message-ID: <7vppwjj5ws.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0kXonM+J92KHs+dW31A_kZ8h9jNqwYn8AqT_V+GJhe_vg@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 6 quoted lines

> Junio C Hamano wrote:
>> 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?