Re: PUSH_HEAD, was Re: disallowing push to currently checked-out branch

[Jay Soffian <jaysoffian@gmail.com>]

On Tue, Feb 17, 2009 at 6:28 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> receive.localBranches = (refuse | allow)
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/77955/focus=78065
>
> In the meantime, we have receive.denyCurrentBranch, which is much superior
> to the localBranches design: it tackles the _real_ issue -- the only
> reason why a current branch cannot be updated lightly is that it might
> have a working directory which would be forced out-of-sync.

Hmpfh.

So both you and Junio have changed your mind since that thread then.
Because in that thread, you propose  receive.guardCurrentBranch, which
was quite similar to today's receive.denyCurrentBranch. Junio then
argues that treating just the checked-out branch as special, as
opposed to all local branches is not the right thing to do:

--- snip ---
http://thread.gmane.org/gmane.comp.version-control.git/77955/focus=78062

Step back a bit and think _why_ you wanted to prevent current branch tip
from getting updated in the first place.  There are two issues:

 * Why is it _current_ branch, and not _these branches_, that can be
   configured by the user to be protected from a push from sideways?

 * Why is it undesirable for the work tree and the index to go out of sync
   with respect to the branch tip to begin with?

The latter is simpler to answer, so let's deal with it first.  The reason
why it is bad is because allowing a push to the current branch interferes
with the work actively being done in the repository, using the work tree
contents.  There is a person, you, who is actively editing the work tree
in order to advance the tip of the branch by making commits.  If the
branch tip moves without your knowing, that destabilizes your working
environment.  Your work tree wanted to make a new commit on top of some
known state, but that state was moved underneath you.  Not good.

When you are using the repository for real work (i.e. advance the tips of
its branches), you want a stable environment.  You do not want its HEAD
bobbing around outside your control, and silently detaching to cause your
later commits to go to unnamed branch without your knowing is just as bad
(which you already correctly objected to).
--- snip ---

And you end up agreeing:

--- snip ---
http://thread.gmane.org/gmane.comp.version-control.git/77955/focus=78062

> Now think.  What if one of these operations you do in the repository to
> advance the tip was to merge from one of _your_ local branches?  Yes,
> you end up merging something you did not expect to merge if you allowed
> a push from sideways to affect that local branch, only because the
> branch happened to be un-checked-out and you implemented this protection
> to forbid only to current branch.  Allowing a push from sideways to any
> local branch destabilizes your work environment, not just the current
> one.

Okay, I am starting to see the light.

How about

	receive.localBranches = (refuse | allow)
--- snip ---

Then the thread died, with receive.localBranches going into TODO, but
never got an implementation. Sometime later, receive.denyCurrentBranch
came along, which is the original idea you proposed, Junio argued
against, and then you agreed.

So, I'm not sure what happened in the intervening time between the
receive.localBranches proposal and the receive.denyCurrentBranch
implementation that suddenly what is basically guardCurrentBranch
became a good idea.

But, I happen to agree with Junio's argument in gmane 77955.

j.