Re: [PATCH] git-bisect.sh: don't accidentally override existing branch "bisect"
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- May 3, 2008, 12:48 UTC
- Message-ID
- <alpine.DEB.1.00.0805031347460.30431@racer>
- In-Reply-To
- <7v8wysy5bz.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 2 May 2008, Junio C Hamano wrote:
Show 21 quoted lines
> 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