Re: disallowing push to currently checked-out branch

On Mon, Feb 16, 2009 at 04:43:03PM -0800, Junio C Hamano wrote:

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.

It is definitely similar.

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.

I think such a marker is a fine idea in general, because it would be
nice to be able to say "what is all state in the repo that I might care
about" (which I think has been talked about several times). In fact, I
have had a similar problem _without_ pushing just by leaving and coming
back in the middle of operations, especially failed ones (e.g., "git
am", realize the patch doesn't apply, forget to --abort, then make more
commits, realize only when you try to "git am" something else, but now
aborting will intermediate work).

I'm not sure that supporting it in receive-pack is necessary. The
current rebase code already detects the situation; it just doesn't
handle it as gracefully as it might. And it doesn't close _all_
possibility for danger, as the example you gave previously shows; the
user can still be surprised by the ref changing.

Whereas improving the local tool support for "rebase --abort" and "am
--abort" to help a user recover from such a situation means that we help
not only the situation of somebody pushing, but also local "I forgot
and changed the repo" situations.

quoted

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.

OK. I'll look at working up a patch.

-Peff