v2Bisect reset: remove bisect refs that may have been packed.

If refs were ever packed in the middle of bisection, the bisect refs were not removed from the "packed-refs" file.

This patch fixes this problem by using "git update-ref -d $ref $hash" in "bisect_clean_state".

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
 git-bisect.sh               |   11 ++++++++++-
 t/t6030-bisect-porcelain.sh |   12 ++++++++++++
 2 files changed, 22 insertions(+), 1 deletions(-)

	Ooops, there was a problem with the previous patch
	if "git bisect reset" was used when not bisecting.

	Sorry.

Christian Couder <chriscool@tuxfamily.org> writes:

Thanks.  Just a few nits.

On top of your patch...

 - You forgot to remove one "removal of filesystem refs";
 - for-each-ref takes more than one patterns.

 git-bisect.sh |    9 ++-------
 1 files changed, 2 insertions(+), 7 deletions(-)

Junio C Hamano schrieb:

If you also swap %(refname) and %(objectname), then this is also not prone to whitespace in refnames. (Yes, I know, there shouldn't be such, but...)

-- Hannes

Johannes Sixt <j.sixt@viscovery.net> wrote:

What's this obsession with whitespace in refnames? Twice in like two days people are talking about whitespace in refnames.

WHITESPACE IS NOT PERMITTED IN REFNAMES.

Do we need to apply the following patch, to keep people from creating refs by hand with whitespace in them? Is this really that common?

	git rev-parse HEAD >'.git/refs/heads/..i have spaces hah!'

On Thu, Nov 15, 2007 at 03:49:34AM -0500, Shawn O. Pearce wrote:

I even had Junio convinced at one point!

I am not actually creating such refs, but I think my brain was still fried from the URL encoding discussion, and I was overly paranoid about spaces.

-Peff

Hi,

On Thu, 15 Nov 2007, Jeff King wrote:

Yeah, I'm really sorry I started that. It was meant to do good, but did bad. Oh, well. The road to hell is paved with good intentions.

Ciao, Dscho

Junio C Hamano <gitster@pobox.com> writes:

Ooops. 'test -d "$GIT_DIR/refs/bisect"' is used as a signal that we are bisecting for the rest of the code, so we cannot lose that rm -fr there.

I think a longer term clean-up would be not to treat "bisect" as a reserved branch name but use detached HEAD while bisecting. But that is a larger topic.

We do not need to pipe "echo" to "sed" only to strip refs/heads/ from the beginning. We are assuming not-so-ancient shells these days.

Also there is no need to avoid assuming \012 is the LF; we do not run on EBCDIC, sorry. Other parts of the script already uses tr to convert separator to LF that way.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 git-bisect.sh |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

Junio C Hamano <gitster@pobox.com> writes:

What's wrong with sed?

-Miles

El 15/11/2007, a las 10:29, Miles Bader escribió:

Nothing, but using it means forking a new process unnecessarily, and the shorter form without sed is arguably more readable:

- echo "$head" | sed 's#^refs/heads/##' >"$GIT_DIR/head-name" + echo "${head#refs/heads/}" >"$GIT_DIR/head-name"

Cheers, Wincent

Wincent Colaiuta <win@wincent.com> writes:

Er, I suppose -- if you are acquainted with that particular shell variable syntax (I suspect knowledge of sed is far more widespread).

[personally, I know that syntax has something to do with replacing something with something else, but really haven't much clue other than that, and I always _thought_ it was bash-specific and so avoided using any of that stuff.]

-miles

Miles Bader wrote:

It says "remove refs/heads/ from the beginning of the string pointed to by $head".

It's not a bashism. Some extensions to that syntax are though (I think). If you want to be sure of portability, use sed instead. git uses this syntax often enough that it's worth using everywhere, but usually only in porcelain commands which one can relatively safely assume are run on at least decently up-to-date developer workstations.

You'll note that stuff that absolutely *has* to reside server-side are entirely in C.

Andreas Ericsson <ae@op5.se> writes:

General replace anywhere.

Guffaw.

Huh? It is used throughout. That's why "make install" will install xxx.sh scripts as xxx after possibly replacing the initial #!/bin/sh line with a shell known to be reasonably conformant on a particular system.

This removes the last instance of making a ref by hand with "echo SHA1 >.git/refs/$refname" from the script and replaces it with update-ref.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 git-bisect.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

When switching to a new rev, we first made "new-bisect" branch to point at the chosen commit, attempt to switch to it, and then finally renamed the new-bisect branch to bisect by hand when successful. This is so that we can catch checkout failure (your local modification may interfere with switching to the chosen version) without losing information on which commit the next attempt should be made.

Rewrite it using a more modern form but without breaking the safety.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 git-bisect.sh |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

On Nov 15, 2007 7:09 PM, David Kastrup <dak@gnu.org> wrote:

I don't think that's really a fair characterization -- almost all of the autoconf sed portability caveats concern weird corner cases in the dusty corners of the language (and some are "common" issues with other tools, i.e., avoiding ^ and $ inside of regexp groups).

For typical straightforward usage, there seems little problem.

[The main portability problems I've actually _noticed_ with sed are the "-e" versus ";" issue and what happens with "\n" in various contexts...]

-Miles

"Miles Bader" <miles@gnu.org> writes:

What about character classes containing the pattern delimiter, \+, \?, \|, nested grouping, anchors in groups, * after groups? That's all rather straightforward usage.

David Kastrup <dak@gnu.org> writes:

You're right that the regexp stuff is not really "dusty corners", but none of those affect typical sed usage I think -- most sed usage being really rather simple (and the old "regexps differ between traditional unix tools" issue tends to dampen enthusiasm for really complex regexps with those tools).

I looked over the various random uses of sed I have locally (a couple of hundred instances), and the only thing which would potentially affect any of them would be the SVR3 thing about no nested groups (does anybody actually care about SVR3 though?!?).

-Miles