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

From: Junio C Hamano <gitster@pobox.com>
Date: May 21, 2013, 20:24 UTC
Message-ID: <7vppwkm682.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0m3QP_eE14y8UoJ+HeFzkKM=1nVKAnYJcTrwQMp+Atphg@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 10 quoted lines

> Junio C Hamano wrote:
>> Is there?  I do not think "volatile" is particularly a good
>> description for this, but showing what is pushed as a concrete
>> branch name feels like a good improvement to me, at least in
>> principle.
>
> Okay.  I used "volatile", because push does not lock HEAD when the
> operation begins, even though it performs a super-late resolution (in
> the transport-layer); HEAD is not guaranteed to remain invariant in
> that time.  Suggest nicer wording?

In general, when a command is working in your repository with a working tree, we do not make any such promise that it keeps operationg normally when you pull the rug under its feet from another terminal ("git checkout maint" running at the same time "git pull" would not have a chance to work correctly). Some are safe (like "git push" racing with "git checkout maint" that would not have to look at what the current branch is) and some are not (like "git push github" racing with "git checkout maint && git push origin HEAD:preview").

I view the value of this topic purely as "showing a real branch name when that is what we actually pushed is a lot more preferrable than showing HEAD, especially because the user may see it in the terminal scrollback buffer hours after it happened". Explaining this patch as "we avoid issues from simultaneously flipping HEAD by resolving early" gives a false sense of security to the reader, as "early" has to happen early enough for the patch to really avoid the issue, but you are not in control of when the user does that flipping in the other terminal.