git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* [PATCH 0/2] run-command: fix Unix PATH lookup
@ 2018-10-24  7:36 Jeff King
  2018-10-24  7:37 ` [PATCH 1/2] t5410: use longer path for sample script Jeff King
  2018-10-24  7:38 ` [PATCH 2/2] run-command: mark path lookup errors with ENOENT Jeff King
  0 siblings, 2 replies; 8+ messages in thread
From: Jeff King @ 2018-10-24  7:36 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano

This series fixes a bug where run-command.c accidentally runs commands
from the current directory when they are not found in the $PATH.

The second patch is the interesting one. The first one is just a
necessary cleanup. Possibly this should be split into two topics: the
second patch slated for maint, and then the first one as an independent
fixup on tb/filter-alternate-refs (which is in master).

  [1/2]: t5410: use longer path for sample script
  [2/2]: run-command: mark path lookup errors with ENOENT

 run-command.c                      | 20 ++++++++++++++++----
 t/t0061-run-command.sh             | 13 ++++++++++++-
 t/t5410-receive-pack-alternates.sh |  2 +-
 3 files changed, 29 insertions(+), 6 deletions(-)

-Peff

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH 1/2] t5410: use longer path for sample script
  2018-10-24  7:36 [PATCH 0/2] run-command: fix Unix PATH lookup Jeff King
@ 2018-10-24  7:37 ` Jeff King
  2018-10-24  8:53   ` Johannes Schindelin
  2018-10-24  7:38 ` [PATCH 2/2] run-command: mark path lookup errors with ENOENT Jeff King
  1 sibling, 1 reply; 8+ messages in thread
From: Jeff King @ 2018-10-24  7:37 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano

t5410 creates a sample script "alternate-refs", and sets
core.alternateRefsCommand to just "alternate-refs". That
shouldn't work, as "." is not in our $PATH, and so we should
not find it.

However, due to a bug in run-command.c, we sometimes find it
anyway! Even more confusing, this bug is only in the
fork-based version of run-command. So the test passes on
Linux (etc), but fails on Windows.

In preparation for fixing the run-command bug, let's use a
more complete path here.

Reported-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Jeff King <peff@peff.net>
---
 t/t5410-receive-pack-alternates.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t5410-receive-pack-alternates.sh b/t/t5410-receive-pack-alternates.sh
index 457c20c2a5..f00d0da860 100755
--- a/t/t5410-receive-pack-alternates.sh
+++ b/t/t5410-receive-pack-alternates.sh
@@ -23,7 +23,7 @@ test_expect_success 'with core.alternateRefsCommand' '
 			--format="%(objectname)" \
 			refs/heads/public/
 	EOF
-	test_config -C fork core.alternateRefsCommand alternate-refs &&
+	test_config -C fork core.alternateRefsCommand ./alternate-refs &&
 	git rev-parse public/branch >expect &&
 	printf "0000" | git receive-pack fork >actual &&
 	extract_haves <actual >actual.haves &&
-- 
2.19.1.1094.gd480080bf6


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH 2/2] run-command: mark path lookup errors with ENOENT
  2018-10-24  7:36 [PATCH 0/2] run-command: fix Unix PATH lookup Jeff King
  2018-10-24  7:37 ` [PATCH 1/2] t5410: use longer path for sample script Jeff King
@ 2018-10-24  7:38 ` Jeff King
  2018-10-24  9:01   ` Johannes Schindelin
  1 sibling, 1 reply; 8+ messages in thread
From: Jeff King @ 2018-10-24  7:38 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano

Since commit e3a434468f (run-command: use the
async-signal-safe execv instead of execvp, 2017-04-19),
prepare_cmd() does its own PATH lookup for any commands we
run (on non-Windows platforms).

However, its logic does not match the old execvp call when
we fail to find a matching entry in the PATH. Instead of
feeding the name directly to execv, execvp would consider
that an ENOENT error. By continuing and passing the name
directly to execv, we effectively behave as if "." was
included at the end of the PATH. This can have confusing and
even dangerous results.

The fix itself is pretty straight-forward. There's a new
test in t0061 to cover this explicitly, and I've also added
a duplicate of the ENOENT test to ensure that we return the
correct errno for this case.

Signed-off-by: Jeff King <peff@peff.net>
---
 run-command.c          | 20 ++++++++++++++++----
 t/t0061-run-command.sh | 13 ++++++++++++-
 2 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/run-command.c b/run-command.c
index 84b883c213..639ea5ac33 100644
--- a/run-command.c
+++ b/run-command.c
@@ -380,7 +380,7 @@ static void child_err_spew(struct child_process *cmd, struct child_err *cerr)
 	set_error_routine(old_errfn);
 }
 
-static void prepare_cmd(struct argv_array *out, const struct child_process *cmd)
+static int prepare_cmd(struct argv_array *out, const struct child_process *cmd)
 {
 	if (!cmd->argv[0])
 		BUG("command is empty");
@@ -403,16 +403,22 @@ static void prepare_cmd(struct argv_array *out, const struct child_process *cmd)
 	/*
 	 * If there are no '/' characters in the command then perform a path
 	 * lookup and use the resolved path as the command to exec.  If there
-	 * are no '/' characters or if the command wasn't found in the path,
-	 * have exec attempt to invoke the command directly.
+	 * are '/' characters, we have exec attempt to invoke the command
+	 * directly.
 	 */
 	if (!strchr(out->argv[1], '/')) {
 		char *program = locate_in_PATH(out->argv[1]);
 		if (program) {
 			free((char *)out->argv[1]);
 			out->argv[1] = program;
+		} else {
+			argv_array_clear(out);
+			errno = ENOENT;
+			return -1;
 		}
 	}
+
+	return 0;
 }
 
 static char **prep_childenv(const char *const *deltaenv)
@@ -719,6 +725,12 @@ int start_command(struct child_process *cmd)
 	struct child_err cerr;
 	struct atfork_state as;
 
+	if (prepare_cmd(&argv, cmd) < 0) {
+		failed_errno = errno;
+		cmd->pid = -1;
+		goto end_of_spawn;
+	}
+
 	if (pipe(notify_pipe))
 		notify_pipe[0] = notify_pipe[1] = -1;
 
@@ -729,7 +741,6 @@ int start_command(struct child_process *cmd)
 		set_cloexec(null_fd);
 	}
 
-	prepare_cmd(&argv, cmd);
 	childenv = prep_childenv(cmd->env);
 	atfork_prepare(&as);
 
@@ -910,6 +921,7 @@ int start_command(struct child_process *cmd)
 }
 #endif
 
+end_of_spawn:
 	if (cmd->pid < 0) {
 		if (need_in)
 			close_pair(fdin);
diff --git a/t/t0061-run-command.sh b/t/t0061-run-command.sh
index 3e131c5325..cf932c8514 100755
--- a/t/t0061-run-command.sh
+++ b/t/t0061-run-command.sh
@@ -12,10 +12,14 @@ cat >hello-script <<-EOF
 	cat hello-script
 EOF
 
-test_expect_success 'start_command reports ENOENT' '
+test_expect_success 'start_command reports ENOENT (slash)' '
 	test-tool run-command start-command-ENOENT ./does-not-exist
 '
 
+test_expect_success 'start_command reports ENOENT (no slash)' '
+	test-tool run-command start-command-ENOENT does-not-exist
+'
+
 test_expect_success 'run_command can run a command' '
 	cat hello-script >hello.sh &&
 	chmod +x hello.sh &&
@@ -25,6 +29,13 @@ test_expect_success 'run_command can run a command' '
 	test_must_be_empty err
 '
 
+test_expect_success 'run_command is restricted to PATH' '
+	write_script should-not-run <<-\EOF &&
+	echo yikes
+	EOF
+	test_must_fail test-tool run-command run-command should-not-run
+'
+
 test_expect_success !MINGW 'run_command can run a script without a #! line' '
 	cat >hello <<-\EOF &&
 	cat hello-script
-- 
2.19.1.1094.gd480080bf6

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2] t5410: use longer path for sample script
  2018-10-24  7:37 ` [PATCH 1/2] t5410: use longer path for sample script Jeff King
@ 2018-10-24  8:53   ` Johannes Schindelin
  2018-10-25  1:15     ` Junio C Hamano
  0 siblings, 1 reply; 8+ messages in thread
From: Johannes Schindelin @ 2018-10-24  8:53 UTC (permalink / raw)
  To: Jeff King; +Cc: git, Junio C Hamano

Hi Peff,

On Wed, 24 Oct 2018, Jeff King wrote:

> t5410 creates a sample script "alternate-refs", and sets
> core.alternateRefsCommand to just "alternate-refs". That
> shouldn't work, as "." is not in our $PATH, and so we should
> not find it.
> 
> However, due to a bug in run-command.c, we sometimes find it
> anyway! Even more confusing, this bug is only in the
> fork-based version of run-command. So the test passes on
> Linux (etc), but fails on Windows.
> 
> In preparation for fixing the run-command bug, let's use a
> more complete path here.
> 
> Reported-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Signed-off-by: Jeff King <peff@peff.net>
> ---

Thank you for the fix! I can confirm that the patch works, and the commit
message is stellar, as per usual for your contributions.

BTW since this breaks every single one of our Continuous Builds on
Windows, I would be very much in favor of fast-tracking this to `master`.

Thanks,
Dscho

>  t/t5410-receive-pack-alternates.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/t/t5410-receive-pack-alternates.sh b/t/t5410-receive-pack-alternates.sh
> index 457c20c2a5..f00d0da860 100755
> --- a/t/t5410-receive-pack-alternates.sh
> +++ b/t/t5410-receive-pack-alternates.sh
> @@ -23,7 +23,7 @@ test_expect_success 'with core.alternateRefsCommand' '
>  			--format="%(objectname)" \
>  			refs/heads/public/
>  	EOF
> -	test_config -C fork core.alternateRefsCommand alternate-refs &&
> +	test_config -C fork core.alternateRefsCommand ./alternate-refs &&
>  	git rev-parse public/branch >expect &&
>  	printf "0000" | git receive-pack fork >actual &&
>  	extract_haves <actual >actual.haves &&
> -- 
> 2.19.1.1094.gd480080bf6
> 
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 2/2] run-command: mark path lookup errors with ENOENT
  2018-10-24  7:38 ` [PATCH 2/2] run-command: mark path lookup errors with ENOENT Jeff King
@ 2018-10-24  9:01   ` Johannes Schindelin
  2018-10-24  9:16     ` Jeff King
  0 siblings, 1 reply; 8+ messages in thread
From: Johannes Schindelin @ 2018-10-24  9:01 UTC (permalink / raw)
  To: Jeff King; +Cc: git, Junio C Hamano

Hi Peff,

On Wed, 24 Oct 2018, Jeff King wrote:

> Since commit e3a434468f (run-command: use the
> async-signal-safe execv instead of execvp, 2017-04-19),
> prepare_cmd() does its own PATH lookup for any commands we
> run (on non-Windows platforms).
> 
> However, its logic does not match the old execvp call when
> we fail to find a matching entry in the PATH. Instead of
> feeding the name directly to execv, execvp would consider
> that an ENOENT error. By continuing and passing the name
> directly to execv, we effectively behave as if "." was
> included at the end of the PATH. This can have confusing and
> even dangerous results.

For the record, I tried to come up with an attack vector to exploit this,
and failed to find one.

> The fix itself is pretty straight-forward. There's a new
> test in t0061 to cover this explicitly, and I've also added
> a duplicate of the ENOENT test to ensure that we return the
> correct errno for this case.
> 
> Signed-off-by: Jeff King <peff@peff.net>
> ---
>  run-command.c          | 20 ++++++++++++++++----
>  t/t0061-run-command.sh | 13 ++++++++++++-
>  2 files changed, 28 insertions(+), 5 deletions(-)
> 
> diff --git a/run-command.c b/run-command.c
> index 84b883c213..639ea5ac33 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -380,7 +380,7 @@ static void child_err_spew(struct child_process *cmd, struct child_err *cerr)
>  	set_error_routine(old_errfn);
>  }
>  
> -static void prepare_cmd(struct argv_array *out, const struct child_process *cmd)
> +static int prepare_cmd(struct argv_array *out, const struct child_process *cmd)

I always like when we change functions to return a value that can then
indicate an error, making the libification effort so much easier.

>  {
>  	if (!cmd->argv[0])
>  		BUG("command is empty");
> @@ -403,16 +403,22 @@ static void prepare_cmd(struct argv_array *out, const struct child_process *cmd)
>  	/*
>  	 * If there are no '/' characters in the command then perform a path
>  	 * lookup and use the resolved path as the command to exec.  If there
> -	 * are no '/' characters or if the command wasn't found in the path,
> -	 * have exec attempt to invoke the command directly.
> +	 * are '/' characters, we have exec attempt to invoke the command
> +	 * directly.

Nice. I would have probably forgotten about that comment.

>  	 */
>  	if (!strchr(out->argv[1], '/')) {
>  		char *program = locate_in_PATH(out->argv[1]);
>  		if (program) {
>  			free((char *)out->argv[1]);
>  			out->argv[1] = program;
> +		} else {
> +			argv_array_clear(out);
> +			errno = ENOENT;
> +			return -1;
>  		}
>  	}
> +
> +	return 0;
>  }
>  
>  static char **prep_childenv(const char *const *deltaenv)
> @@ -719,6 +725,12 @@ int start_command(struct child_process *cmd)
>  	struct child_err cerr;
>  	struct atfork_state as;
>  
> +	if (prepare_cmd(&argv, cmd) < 0) {
> +		failed_errno = errno;
> +		cmd->pid = -1;
> +		goto end_of_spawn;
> +	}
> +
>  	if (pipe(notify_pipe))
>  		notify_pipe[0] = notify_pipe[1] = -1;
>  
> @@ -729,7 +741,6 @@ int start_command(struct child_process *cmd)
>  		set_cloexec(null_fd);
>  	}
>  
> -	prepare_cmd(&argv, cmd);
>  	childenv = prep_childenv(cmd->env);
>  	atfork_prepare(&as);
>  
> @@ -910,6 +921,7 @@ int start_command(struct child_process *cmd)
>  }
>  #endif
>  
> +end_of_spawn:

Sadly, this fails to build on Windows:

	run-command.c: In function 'start_command':
	run-command.c:924:1: error: label 'end_of_spawn' defined but not used [-Werror=unused-label]
	 end_of_spawn:
	 ^~~~~~~~~~~~

How about squashing in this diff:

-- snip --
diff --git a/run-command.c b/run-command.c
index 639ea5ac3366..3f03795a5995 100644
--- a/run-command.c
+++ b/run-command.c
@@ -918,6 +918,8 @@ int start_command(struct child_process *cmd)
 		close(fhout);
 	if (fherr != 2)
 		close(fherr);
+
+	goto end_of_spawn;
 }
 #endif
 
-- snap --

I can confirm that the result compiles and passes t0061.

Thanks,
Dscho

>  	if (cmd->pid < 0) {
>  		if (need_in)
>  			close_pair(fdin);
> diff --git a/t/t0061-run-command.sh b/t/t0061-run-command.sh
> index 3e131c5325..cf932c8514 100755
> --- a/t/t0061-run-command.sh
> +++ b/t/t0061-run-command.sh
> @@ -12,10 +12,14 @@ cat >hello-script <<-EOF
>  	cat hello-script
>  EOF
>  
> -test_expect_success 'start_command reports ENOENT' '
> +test_expect_success 'start_command reports ENOENT (slash)' '
>  	test-tool run-command start-command-ENOENT ./does-not-exist
>  '
>  
> +test_expect_success 'start_command reports ENOENT (no slash)' '
> +	test-tool run-command start-command-ENOENT does-not-exist
> +'
> +
>  test_expect_success 'run_command can run a command' '
>  	cat hello-script >hello.sh &&
>  	chmod +x hello.sh &&
> @@ -25,6 +29,13 @@ test_expect_success 'run_command can run a command' '
>  	test_must_be_empty err
>  '
>  
> +test_expect_success 'run_command is restricted to PATH' '
> +	write_script should-not-run <<-\EOF &&
> +	echo yikes
> +	EOF
> +	test_must_fail test-tool run-command run-command should-not-run
> +'
> +
>  test_expect_success !MINGW 'run_command can run a script without a #! line' '
>  	cat >hello <<-\EOF &&
>  	cat hello-script
> -- 
> 2.19.1.1094.gd480080bf6
> 

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH 2/2] run-command: mark path lookup errors with ENOENT
  2018-10-24  9:01   ` Johannes Schindelin
@ 2018-10-24  9:16     ` Jeff King
  2018-10-24  9:25       ` Johannes Schindelin
  0 siblings, 1 reply; 8+ messages in thread
From: Jeff King @ 2018-10-24  9:16 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git, Junio C Hamano

On Wed, Oct 24, 2018 at 11:01:54AM +0200, Johannes Schindelin wrote:

> > @@ -910,6 +921,7 @@ int start_command(struct child_process *cmd)
> >  }
> >  #endif
> >  
> > +end_of_spawn:
> 
> Sadly, this fails to build on Windows:
> 
> 	run-command.c: In function 'start_command':
> 	run-command.c:924:1: error: label 'end_of_spawn' defined but not used [-Werror=unused-label]
> 	 end_of_spawn:
> 	 ^~~~~~~~~~~~

Doh. I didn't think of that.

> How about squashing in this diff:
> 
> -- snip --
> diff --git a/run-command.c b/run-command.c
> index 639ea5ac3366..3f03795a5995 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -918,6 +918,8 @@ int start_command(struct child_process *cmd)
>  		close(fhout);
>  	if (fherr != 2)
>  		close(fherr);
> +
> +	goto end_of_spawn;
>  }
>  #endif
>  
> -- snap --
> 
> I can confirm that the result compiles and passes t0061.

That leaves the Windows side of the #else with a funny, useless goto
(and without even a matching useless one on the Unix side).  Let's put
it instead inside the half of the #if that actually uses it. Like so
(actually courtesy of Jonathan Nieder):

diff --git a/run-command.c b/run-command.c
index 639ea5ac33..d679cc267c 100644
--- a/run-command.c
+++ b/run-command.c
@@ -868,6 +868,8 @@ int start_command(struct child_process *cmd)
 	argv_array_clear(&argv);
 	free(childenv);
 }
+end_of_spawn:
+
 #else
 {
 	int fhin = 0, fhout = 1, fherr = 2;
@@ -921,7 +923,6 @@ int start_command(struct child_process *cmd)
 }
 #endif
 
-end_of_spawn:
 	if (cmd->pid < 0) {
 		if (need_in)
 			close_pair(fdin);

Thanks for your review!

-Peff

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH 2/2] run-command: mark path lookup errors with ENOENT
  2018-10-24  9:16     ` Jeff King
@ 2018-10-24  9:25       ` Johannes Schindelin
  0 siblings, 0 replies; 8+ messages in thread
From: Johannes Schindelin @ 2018-10-24  9:25 UTC (permalink / raw)
  To: Jeff King; +Cc: git, Junio C Hamano

Hi Peff,

On Wed, 24 Oct 2018, Jeff King wrote:

> On Wed, Oct 24, 2018 at 11:01:54AM +0200, Johannes Schindelin wrote:
> 
> > > @@ -910,6 +921,7 @@ int start_command(struct child_process *cmd)
> > >  }
> > >  #endif
> > >  
> > > +end_of_spawn:
> > 
> > Sadly, this fails to build on Windows:
> > 
> > 	run-command.c: In function 'start_command':
> > 	run-command.c:924:1: error: label 'end_of_spawn' defined but not used [-Werror=unused-label]
> > 	 end_of_spawn:
> > 	 ^~~~~~~~~~~~
> 
> Doh. I didn't think of that.
> 
> > How about squashing in this diff:
> > 
> > -- snip --
> > diff --git a/run-command.c b/run-command.c
> > index 639ea5ac3366..3f03795a5995 100644
> > --- a/run-command.c
> > +++ b/run-command.c
> > @@ -918,6 +918,8 @@ int start_command(struct child_process *cmd)
> >  		close(fhout);
> >  	if (fherr != 2)
> >  		close(fherr);
> > +
> > +	goto end_of_spawn;
> >  }
> >  #endif
> >  
> > -- snap --
> > 
> > I can confirm that the result compiles and passes t0061.
> 
> That leaves the Windows side of the #else with a funny, useless goto
> (and without even a matching useless one on the Unix side).  Let's put
> it instead inside the half of the #if that actually uses it. Like so
> (actually courtesy of Jonathan Nieder):
> 
> diff --git a/run-command.c b/run-command.c
> index 639ea5ac33..d679cc267c 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -868,6 +868,8 @@ int start_command(struct child_process *cmd)
>  	argv_array_clear(&argv);
>  	free(childenv);
>  }
> +end_of_spawn:
> +
>  #else
>  {
>  	int fhin = 0, fhout = 1, fherr = 2;
> @@ -921,7 +923,6 @@ int start_command(struct child_process *cmd)
>  }
>  #endif
>  
> -end_of_spawn:
>  	if (cmd->pid < 0) {
>  		if (need_in)
>  			close_pair(fdin);

That works for me, too.

> Thanks for your review!

You're welcome!

Thanks,
Dscho

> 
> -Peff
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2] t5410: use longer path for sample script
  2018-10-24  8:53   ` Johannes Schindelin
@ 2018-10-25  1:15     ` Junio C Hamano
  0 siblings, 0 replies; 8+ messages in thread
From: Junio C Hamano @ 2018-10-25  1:15 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Jeff King, git

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Wed, 24 Oct 2018, Jeff King wrote:
>
>> t5410 creates a sample script "alternate-refs", and sets
>> core.alternateRefsCommand to just "alternate-refs". That
>> shouldn't work, as "." is not in our $PATH, and so we should
>> not find it.
>> 
>> However, due to a bug in run-command.c, we sometimes find it
>> anyway! Even more confusing, this bug is only in the
>> fork-based version of run-command. So the test passes on
>> Linux (etc), but fails on Windows.
>> 
>> In preparation for fixing the run-command bug, let's use a
>> more complete path here.
>> 
>> Reported-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>> Signed-off-by: Jeff King <peff@peff.net>
>> ---
>
> Thank you for the fix! I can confirm that the patch works, and the commit
> message is stellar, as per usual for your contributions.
>
> BTW since this breaks every single one of our Continuous Builds on
> Windows, I would be very much in favor of fast-tracking this to `master`.
>
> Thanks,
> Dscho

I should note to the public that this one, and the companion patch
2/2, owe greatly to you and Peff's efforts.

Thanks, both.

>
>>  t/t5410-receive-pack-alternates.sh | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/t/t5410-receive-pack-alternates.sh b/t/t5410-receive-pack-alternates.sh
>> index 457c20c2a5..f00d0da860 100755
>> --- a/t/t5410-receive-pack-alternates.sh
>> +++ b/t/t5410-receive-pack-alternates.sh
>> @@ -23,7 +23,7 @@ test_expect_success 'with core.alternateRefsCommand' '
>>  			--format="%(objectname)" \
>>  			refs/heads/public/
>>  	EOF
>> -	test_config -C fork core.alternateRefsCommand alternate-refs &&
>> +	test_config -C fork core.alternateRefsCommand ./alternate-refs &&
>>  	git rev-parse public/branch >expect &&
>>  	printf "0000" | git receive-pack fork >actual &&
>>  	extract_haves <actual >actual.haves &&
>> -- 
>> 2.19.1.1094.gd480080bf6
>> 
>> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2018-10-25  1:15 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-24  7:36 [PATCH 0/2] run-command: fix Unix PATH lookup Jeff King
2018-10-24  7:37 ` [PATCH 1/2] t5410: use longer path for sample script Jeff King
2018-10-24  8:53   ` Johannes Schindelin
2018-10-25  1:15     ` Junio C Hamano
2018-10-24  7:38 ` [PATCH 2/2] run-command: mark path lookup errors with ENOENT Jeff King
2018-10-24  9:01   ` Johannes Schindelin
2018-10-24  9:16     ` Jeff King
2018-10-24  9:25       ` Johannes Schindelin

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).