Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes:
> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html