Re: [PATCH] git-bisect.sh: don't accidentally override existing branch "bisect"

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1362 bytes --]

Hi,

On Fri, 2 May 2008, Junio C Hamano wrote:

> Karl Hasselström <kha@treskal.com> writes:
> 
> > On 2008-04-30 16:46:13 +0000, Gerrit Pape wrote:
> >
> >> If a branch named "bisect" or "new-bisect" already was created in the 
> >> repo by other means than git bisect, doing a git bisect used to 
> >> override the branch without a warning. Now if the branch "bisect" or 
> >> "new-bisect" already exists, and it was not created by git bisect 
> >> itself, git bisect start fails with an appropriate error message. 
> >> Additionally, if checking out a new bisect state fails due to a merge 
> >> problem, git bisect cleans up the temporary branch "new-bisect".
> >
> > Makes me wonder why bisect has to use a branch at all, and not just a 
> > detached HEAD ... I seem to recall this having been discussed before, 
> > but I can't find it now.
> 
> Only because the mechanism predates detached HEAD and no other reason. 
> Whoever wants to update it to use detached HEAD needs to design what 
> should happen when the bisection was started while the HEAD is detached 
> (should we come back to the same HEAD?  how? ...), but other than that I 
> do not offhand see fundamental difficulties.

IMO it should behave as the rebase machinery does: record $(git rev-parse 
HEAD) in the case of a detached HEAD, and go back to that.  It is dead 
easy.

Ciao,
Dscho