From: Junio C Hamano <gitster@pobox.com>
To: "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Fernando Ramos <greenfoo@u92.eu>,
Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH v2] mergetool(vimdiff): allow paths to contain spaces again
Date: Thu, 14 Jul 2022 09:27:33 -0700 [thread overview]
Message-ID: <xmqqy1wv7j7u.fsf@gitster.g> (raw)
In-Reply-To: <pull.1287.v2.git.1657809063728.gitgitgadget@gmail.com> (Johannes Schindelin via GitGitGadget's message of "Thu, 14 Jul 2022 14:31:03 +0000")
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:
> if $base_present
> then
> - eval "$merge_tool_path" \
> - -f "$FINAL_CMD" "$LOCAL" "$BASE" "$REMOTE" "$MERGED"
> + eval '"$merge_tool_path"' \
> + -f "$FINAL_CMD" '"$LOCAL"' '"$BASE"' '"$REMOTE"' '"$MERGED"'
> else
> # If there is no BASE (example: a merge conflict in a new file
> # with the same name created in both braches which didn't exist
> @@ -424,8 +424,8 @@ merge_cmd () {
> FINAL_CMD=$(echo "$FINAL_CMD" | \
> sed -e 's:2b:quit:g' -e 's:3b:2b:g' -e 's:4b:3b:g')
>
> - eval "$merge_tool_path" \
> - -f "$FINAL_CMD" "$LOCAL" "$REMOTE" "$MERGED"
> + eval '"$merge_tool_path"' \
> + -f "$FINAL_CMD" '"$LOCAL"' '"$REMOTE"' '"$MERGED"'
> fi
If there were another syntactic fix we need in the future, we may by
mistake fix one but not the other, and the test we add in this patch
checks only one side but not the other. In a follow-up we may want
to unify the two eval invocations to make the testing of this part
more robust.
But as a minimum and obvious fix, stopping at the above is
appropriate for this patch.
> + ...
> + diff -u expect actual || at_least_one_ko=true
I wonder if we still should care about platforms that need to set
GIT_TEST_CMP_USE_COPIED_CONTEXT while running our tests. If we use
"diff -u" hardcoded like this here, we are declaring that they are
now unwelcome to run our tests.
It might be just the matter of using "cmp -s" here (or run "diff"
without any option). Do we care about emitting the difference in
the output? I doubt it.
> if test "$at_least_one_ko" = "true"
> then
> return 255
Thanks.
prev parent reply other threads:[~2022-07-14 16:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-13 15:42 [PATCH] mergetool(vimdiff): allow paths to contain spaces again Johannes Schindelin via GitGitGadget
2022-07-13 16:22 ` Junio C Hamano
2022-07-13 20:52 ` Fernando Ramos
2022-07-13 20:54 ` Junio C Hamano
2022-07-13 21:08 ` Junio C Hamano
2022-07-13 21:33 ` Fernando Ramos
2022-07-13 21:54 ` Junio C Hamano
2022-07-13 22:06 ` Junio C Hamano
2022-07-13 22:28 ` Fernando Ramos
2022-07-13 22:22 ` Fernando Ramos
2022-07-13 22:33 ` Junio C Hamano
2022-07-14 14:31 ` [PATCH v2] " Johannes Schindelin via GitGitGadget
2022-07-14 16:27 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqy1wv7j7u.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=greenfoo@u92.eu \
--cc=johannes.schindelin@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 NNTP newsgroup(s).