Re: disallowing push to currently checked-out branch

Hi,

On Mon, 16 Feb 2009, Sergio Callegari wrote:

Johannes Schindelin wrote:

quoted

Wrong.  It cries out loud when you detach, not when you commit to a 
detached HEAD.  For good reason: Already at the second commit it would 
stop being funny.

Right, I was wrong in expecting complaints. But... if it cried out at 
the first commit, for many people there would probably not be a second. 

What you are suggesting, though, is that the _pusher_ detaches the HEAD.  
So the _local_ user will never know.

Btw, I am ignorant on this: is there some case where one wants and has 
reasons to commit to a detached head before making a temporary branch on 
it?

Yes.  When you try fixups on a commit you just jumped to, for example.  Or 
when bisecting.

I often use the detached HEAD as kind of a stash during a bisect.  I try 
to fix it there, at the bad commit, and then cherry-pick HEAD@{1} into 
the branch after resetting the bisect.

quoted

quoted

Furthermore, one could do just a bit more than detaching, namely 
store the fact that head got detached and the name of the branch 
where the head was. With this, when the unconscious user types git 
status or git commit the system could alert him that head got 
detached because someone updated the branch behind his shoulders 
from remote...

And of course, you need a way to show the user all the updates the branch
went through while the HEAD was detached, so that the user has a chance of
understanding what happened in the meantime.

So much additional work, just to fix up the shortcomings of the 
'detach' paradigm?  I take it as a clear mark of a not-so-elegant 
design.

  
Well not that much additional work...

when you push to the checked out branch, head gets detached and branch name
(say /ref/heads/master) gets stored (say in .git/pre_push_branch).
when you run status or commit, you realize that there is a pre_push_branch and
you give the warning, saying what the pre_push_branch was.

Of course, you assume there that it was only one push between detaching 
the HEAD and inspecting the mess.

Now, since before the push you were at the tip of that branch, to know 
what happened it should be enough to ask the log (or the diff) from 
pre_push_branch to HEAD. At the first user command that moves HEAD, 
pre_push_branch should get deleted.

And you call that not much work?

Btw, what does happen now if you delete the branch the remote worktree 
is on?

See the related discussion of receive.denyDeleteCurrent.

Ciao,
Dscho