[PATCH 3/4] bisect: fix reading more than one path in "$GIT_DIR/BISECT_NAMES"

[PATCH 3/4] bisect: fix reading more than one path in "$GIT_DIR/BISECT_NAMES"

[Christian Couder]

The implementation of "read_bisect_paths" worked with only one
path in each line of "$GIT_DIR/BISECT_NAMES", but the paths are all
stored on one line by "git-bisect.sh".

So we have to process all the paths that may be on each line.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
 bisect.c |   14 +++++++-------
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/bisect.c b/bisect.c
index 9e779c1..66df05f 100644
--- a/bisect.c
+++ b/bisect.c
@@ -435,17 +435,17 @@ void read_bisect_paths(void)
 		die("Could not open file '%s': %s", filename, strerror(errno));
 
 	while (strbuf_getline(&str, fp, '\n') != EOF) {
-		char *quoted, *dequoted;
+		char *quoted;
+		int res;
+
 		strbuf_trim(&str);
 		quoted = strbuf_detach(&str, NULL);
-		if (!*quoted)
-			continue;
-		dequoted = sq_dequote(quoted);
-		if (!dequoted)
+		res = sq_dequote_to_argv(quoted, &rev_argv,
+					 &rev_argv_nr, &rev_argv_alloc);
+		if (res)
 			die("Badly quoted content in file '%s': %s",
 			    filename, quoted);
-		ALLOC_GROW(rev_argv, rev_argv_nr + 1, rev_argv_alloc);
-		rev_argv[rev_argv_nr++] = dequoted;
+		free(quoted);
 	}
 
 	strbuf_release(&str);
-- 
1.6.2.1.404.gb0085.dirty

Re: [PATCH 3/4] bisect: fix reading more than one path in "$GIT_DIR/BISECT_NAMES"

[Junio C Hamano]

Christian Couder <chriscool@tuxfamily.org> writes:

> The implementation of "read_bisect_paths" worked with only one
> path in each line of "$GIT_DIR/BISECT_NAMES", but the paths are all
> stored on one line by "git-bisect.sh".
>
> So we have to process all the paths that may be on each line.

This is "oops, the previous one is broken", for a series that was not yet
'next' worthy, so I squashed the fix and rebuilt the topic, together with
your other patches.

The series now looks like this:

  $ git log --oneline --boundary master..cc/bisect-filter
  b54809a bisect--helper: string output variables together with "&&"
  fd5a6a8 rev-list: pass "int flags" as last argument of "show_bisect_vars"
  e2c52e1 t6030: test bisecting with paths
  56fac26 bisect: use "bisect--helper" and remove "filter_skipped" function
  650bafa bisect: implement "read_bisect_paths" to read paths in "$GIT_DIR/BISECT_NAMES"
  a79b083 bisect--helper: implement "git bisect--helper"
  29adb27 quote: add "sq_dequote_to_argv" to put unwrapped args in an argv array
  ccc12f5 quote: implement "sq_dequote_many" to unwrap many args in one string
  a292c81 rev-list: call new "filter_skip" function
  58f0b66 rev-list: pass "revs" to "show_bisect_vars"
  41440cf rev-list: make "show_bisect_vars" non static
  a650efd rev-list: move code to show bisect vars into its own function
  2bc0667 rev-list: move bisect related code into its own file
  7cc17b8 rev-list: make "bisect_list" variable local to "cmd_rev_list"
  52ffe77 refs: add "for_each_bisect_ref" function
  -89fbda2 Merge branch 'maint'

I've tweaked a few patches before applying, but they all looked basically
sane.  Unless I hear from other people in a few days , I'd say we merge it
to 'next' and start cooking it.

Thanks.

Re: [PATCH 3/4] bisect: fix reading more than one path in "$GIT_DIR/BISECT_NAMES"

[Christian Couder]

Le lundi 30 mars 2009, Junio C Hamano a écrit :
> Christian Couder <chriscool@tuxfamily.org> writes:
> > The implementation of "read_bisect_paths" worked with only one
> > path in each line of "$GIT_DIR/BISECT_NAMES", but the paths are all
> > stored on one line by "git-bisect.sh".
> >
> > So we have to process all the paths that may be on each line.
>
> This is "oops, the previous one is broken", for a series that was not yet
> 'next' worthy, so I squashed the fix and rebuilt the topic, together with
> your other patches.

No problem.

> The series now looks like this:

[...]

> I've tweaked a few patches before applying, but they all looked basically
> sane.  Unless I hear from other people in a few days , I'd say we merge
> it to 'next' and start cooking it.

Thanks,
Christian.