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.

  

I am not sure that I get what you mean.  But if I get it right, 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.
Otherwise the local user would find out that a push happened behind his 
shoulder right at the first "status" or "commit", as he was expecting to 
be on a branch and he finds himself off it.

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, and it becomes the tip of 
a short-lived development burst... It is not anymore just a way to peek 
at some status as I remember it was initially introduced, is it?

quoted

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.
  

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...
Which I guess is what the local user should want. He expected to be at 
some commit at the tip of some branch and he needs to find out what has 
happened between that commit and the new tip of that branch. Does he 
really need to know in how many and what precise push operations the 
branch tip moved?

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.
    

And you call that not much work?

  

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.

Which brings me back to my former consideration.

I initially thought of detaching head because it looks like a way to 
save a bit of info that I would like to see preserved.  When someone 
pushes in my repo, if my current branch tip moves, at the first action 
that I attempt on the repo I would like to see a big alert that it did 
and have an easy way to find out at what commit I was before the push 
happened.  Otherwise, I cannot really find out what the push precisely 
changed, I cannot easily revert it if it was wrong, etc.

Sergio