Re: disallowing push to currently checked-out branch

> Johannes Schindelin wrote:
>
> > What you are suggesting, though, is that the _pusher_ detaches the 
> > HEAD.  So the _local_ user will never know.
>
> the only reason why the local user cannot know is precisely because "git 
> commit" does not complain if you call it from a detached head.

> > > 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.
>
> Interesting.  But it is sort of abusing the detached head thing, isn't 
> it? You use it as a temporary unnamed branch,

> > Of course, you assume there that it was only one push between 
> > detaching the HEAD and inspecting the mess.
>
> After the first push, the head is already detached, so pre_push_branch 
> does not get touched by the second, the third, the forth push, etc...

> > > 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?
>
> I tried.  With current git 1.6.1.3, head remains pointing at a non 
> existent branch and git status thinks that you need to do your initial 
> commit. When you commit, the deleted branch is immediately recreated 
> from scratch and you loose the history that got you at that status.