Re: [PATCH v14 5/8] bisect: introduce --no-checkout support into porcelain.

4 messages, 3 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH v14 5/8] bisect: introduce --no-checkout support into porcelain.

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:51:43

Jon Seymour [off-list ref] writes:

quoted hunk

+	BISECT_MODE=
 	while [ $# -gt 0 ]; do
 	    arg="$1"
 	    case "$arg" in

@@ -76,6 +79,11 @@ bisect_start() {
 		shift
 		break
 		;;
+	    --no-checkout)
+		BISECT_MODE=--no-checkout;
+		shift ;;
+	    --*)
+		die "$(eval_gettext "unrecognised option: '\$arg'")" ;;
 	    *)
 		rev=$(git rev-parse -q --verify "$arg^{commit}") || {
 		    test $has_double_dash -eq 1 &&
@@ -107,7 +115,11 @@ bisect_start() {
 	then
 		# Reset to the rev from where we started.
 		start_head=$(cat "$GIT_DIR/BISECT_START")
-		git checkout "$start_head" -- || exit
+		if test "$BISECT_MODE" = "--no-checkout"; then
+		    git update-ref --no-deref HEAD "$start_head"
+		else
+		    git checkout "$start_head" --
+		fi

Just a minor worry but I would not be surprised if somebody's "test"
implementation barfs upon:

	test "--no-checkout" = "--no-checkout"

mistaking the string with a dash at the beginning as an option unknown to
it. That is why we often have "z$variable" in our comparison, like so:

	if test "z$BISECT_MODE" = "z--no-checkout"
        then
        	git update-ref --no-deref BISECT_HEAD "$start_head"
	else
        	git checkout "$start_head" --
	fi

-	git rev-parse --sq-quote "$@" >"$GIT_DIR/BISECT_NAMES" &&
+	git rev-parse --sq-quote "$@" >"$GIT_DIR/BISECT_NAMES"
+	echo "$BISECT_MODE" > "$GIT_DIR/BISECT_MODE" &&

&&?

Re: [PATCH v14 5/8] bisect: introduce --no-checkout support into porcelain.

From: Jonathan Nieder <hidden>
Date: 2016-06-15 22:51:44

Junio C Hamano wrote:

Just a minor worry but I would not be surprised if somebody's "test"
implementation barfs upon:

	test "--no-checkout" = "--no-checkout"

mistaking the string with a dash at the beginning as an option unknown to
it. That is why we often have "z$variable" in our comparison, like so:

	if test "z$BISECT_MODE" = "z--no-checkout"

Hmm.

	$ git grep -e 'test "\$' | wc -l
	712
	$ git grep -e 'test ".\$' | wc -l
	183

We are very inconsistent about such usage, generally, and of course
POSIX is very clear about the 'z' not being needed in a three-argument
"test" used for string comparison.  Is there any platform that is
usable for git (e.g., that implements "$( ... )") and has that
problem?

Re: [PATCH v14 5/8] bisect: introduce --no-checkout support into porcelain.

From: Jon Seymour <hidden>
Date: 2016-06-15 22:51:44

On Thu, Aug 4, 2011 at 4:57 AM, Jonathan Nieder [off-list ref] wrote:

Junio C Hamano wrote:

quoted

Just a minor worry but I would not be surprised if somebody's "test"
implementation barfs upon:

      test "--no-checkout" = "--no-checkout"

mistaking the string with a dash at the beginning as an option unknown to
it. That is why we often have "z$variable" in our comparison, like so:

      if test "z$BISECT_MODE" = "z--no-checkout"

Hmm.

       $ git grep -e 'test "\$' | wc -l
       712
       $ git grep -e 'test ".\$' | wc -l
       183

We are very inconsistent about such usage, generally, and of course
POSIX is very clear about the 'z' not being needed in a three-argument
"test" used for string comparison.  Is there any platform that is
usable for git (e.g., that implements "$( ... )") and has that
problem?

Thanks. Applied.

Re: [PATCH v14 5/8] bisect: introduce --no-checkout support into porcelain.

From: Jonathan Nieder <hidden>
Date: 2016-06-15 22:51:44

Jon Seymour wrote:

On Thu, Aug 4, 2011 at 4:57 AM, Jonathan Nieder [off-list ref] wrote:

quoted

We are very inconsistent about such usage, generally, and of course
POSIX is very clear about the 'z' not being needed in a three-argument
"test" used for string comparison.  Is there any platform that is
usable for git (e.g., that implements "$( ... )") and has that
problem?

Thanks. Applied.

Hm --- I was just asking a question, not meant to be rhetorical.  I
guess the question was applied, or that you inferred some patch from
it. :)

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help