Re: disallowing push to currently checked-out branch

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 16, 2009, 20:09 UTC
Message-ID: <alpine.DEB.1.00.0902162103580.6289@intel-tinevez-2-302>
In-Reply-To: <4999BD54.8090805@gmail.com>

Hi,

On Mon, 16 Feb 2009, Sergio Callegari wrote:

Show 7 quoted lines

> Johannes Schindelin wrote:
> > 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.

Show 21 quoted lines

> > > 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