Re: disallowing push to currently checked-out branch

Hi,

On Tue, 17 Feb 2009, Sergio Callegari wrote:

Johannes Schindelin wrote:

quoted

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.

No, the only reason is that you sneakily detached the HEAD behind his 
back.  It is not possible in physical life -- at least not without the 
owner of the head noticing -- and it should not be possible with Git, 
either.

All this "we need more complaining" is just a fix up for a failed design.

quoted

quoted

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,

That is exactly what a detached HEAD is.

quoted

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

Oh, so the user should be really fscked for not realizing just how much 
happened in the meantime?

quoted

quoted

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.

quoted

And you call that not much work?

That point is still valid.  If you have to do too much to make your idea 
work, if you have to bolt on this and that, it is a sure sign that the 
design is borked.

quoted

quoted

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.

As I remarked already, this is a bug that is actively being squashed.

Of course, you can go on and on and on with the detached HEAD ide, but so 
far you haven't convinced me that this is a sensible thing to do.

Ciao,
Dscho