Re: disallowing push to currently checked-out branch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Tue, 17 Feb 2009, Sergio Callegari wrote:

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

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

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

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

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.

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

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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux