Hi,
On Mon, 16 Feb 2009, Sergio Callegari wrote:
> 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.
> > > 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
--
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
