Hi, On Fri, 2 May 2008, Junio C Hamano wrote: > Karl Hasselström <kha@xxxxxxxxxxx> 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
