Re: disallowing push to currently checked-out branch

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 17, 2009, 00:43 UTC
Message-ID: <7vocx1evvs.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20090217002352.GA23507@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 14 quoted lines

> On Mon, Feb 16, 2009 at 03:23:00PM -0800, Junio C Hamano wrote:
>
>> >   1. How can we improve this situation?
>> 
>> The situation you described is all about "don't allow a push that is NOT
>> CONTROLLED BY YOU and that can interfere with what you are doing into a
>> live repository", and you are right, we have operations that deliberately
>> detach the HEAD and expect nobody mucks with the branch.
>
> I don't agree that it has to be a push not controlled by you. I have
> many times left a rebase-in-progress sitting in a repository, either
> accidentally because I meant to "--abort" it after a conflict but
> forgot, or because I got interrupted during an interactive edit and
> needed to come back to it.

That sounds similar to saying "I left my editor open without saving my changes, and accidentally opened another instance of an editor from a different terminal and edited the same file, the result is a mess". The editors protect users from such a situation by locking the file they are editing.

Perhaps operations that detaches HEAD (rebase and perhaps sequencer) can all agree to use a single marker file that says "Do not mess with these refs via push or fetch" and make receive-pack and fetch honor that? Then the issue you raised in your earlier message about receive-pack having to know random states random set of tools leave will be alleviated. We need to make sure that the marker is cleaned up correctly when the command is done with the lock, of course.

If we were to go that route, I think the same receive.denyCurrentBranch configuration variable can and should be used to control this, even though its name originally comes from the most visible operation that can cause the confusion (i.e. "pushing into the current branch"). It is about protecting the person who is currently using the work tree, or who will use the work tree next.

> I am really just proposing that the "ref was not what we expected"
> message to better indicate what is going on, and how the user might get
> out of it. Do you not agree with that?

The recovery recipe you described looked good.