On 2020-03-22 at 11:44:33, András Kucsma wrote:
> My proposal patch is to take advantage of find_last_dir_sep function's
> OS specific directory separator knowledge.
> I posted the diff below, which is also available on github here:
> https://github.com/git/git/compare/maint...r0mai:fix-prepare_cmd-windows-maint
> 
> diff --git a/run-command.c b/run-command.c
> index f5e1149f9b..9fcc12ebf9 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -421,12 +421,12 @@ static int 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 '/' characters, we have exec attempt to invoke the command
> -     * directly.
> +     * If there are no dir separator characters in the command then perform
> +     * a path lookup and use the resolved path as the command to exec. If
> +     * there are dir separator characters, we have exec attempt to invoke
> +     * the command directly.
>       */
> -    if (!strchr(out->argv[1], '/')) {
> +    if (find_last_dir_sep(out->argv[1]) == NULL) {
>          char *program = locate_in_PATH(out->argv[1]);

This function (locate_in_PATH) specifically says it is not to be used on
Windows because it doesn't work properly there due to file extensions.
I'm pretty sure a proper solution would involve touching that as well,
although your solution does indeed fix the issue you reported.  That
function also uses a colon-separated PATH, which I'm not sure will work
in all cases on Windows (although maybe it will).

From looking at this earlier, I think the problem here is that we're
trying to use the Unix codepaths (on Cygwin) and then expecting those to
handle Windows-style paths, which they aren't intended to do.  This is
likely one of many problems on Cygwin.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204