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.
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?
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?
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.
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
