From: "Rubén Justo" <rjusto@gmail.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Git List <git@vger.kernel.org>, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v4] branch: support for shortcuts like @{-1}, completed
Date: Sun, 9 Oct 2022 01:28:51 +0200 [thread overview]
Message-ID: <32e4f8cf-696c-317d-236b-0f64c1398a01@gmail.com> (raw)
In-Reply-To: <CAPig+cRxy5C+CqUOzmhe16j+hssxsygha3huVga8tLJ+imM4Hw@mail.gmail.com>
On 8/10/22 19:10, Eric Sunshine wrote:
>> All of this involves two files and that is how it is done almost everywhere
>> except in some places where it looks like an 'older way' (test_i18ngrep) of
>> doing it. Is there any reason to do it this way and not using variables,
>> process substitution,..?
>
> An invocation such as:
>
> test $(git foo) = $(git bar) &&
>
> throws away the exit-code from the two commands, which means we'd miss
> if one or the other (or both) crashed, especially if the crash was
> after the command produced the correct output. These days we try to
> avoid losing the exit command of Git commands. It's possible to avoid
> losing the exit-code by using variables:
>
> expect=$(git foo) &&
> actual=$(git bar) &&
> test "$expect" = "$actual" &&
>
> but, if the expected and actual output don't match, you don't learn
> much (other than that they failed). You could address that by showing
> a message saying what failed:
>
> expect=... &&
> actual=... &&
> if test "$expect" != "$actual"
> then
> echo "expect not match actual"
> # maybe emit $expect and $actual too
> fi
>
> However, `test_cmp` gives you that behavior for free, and it emits a
> helpful "diff" upon failure, so these days we usually go with
> `test_cmp`.
>
This is already out of the subject, the patch, of this thread, so sorry,
but the context is worth of it.
I understand the possibility of losing exit codes or segfaults in
subcommands or pipes, but I'm more thinking in the element to compare to.
Having something like:
test_cmp_str () {
test -f "$1" || BUG "first argument must be a file"
if test "$#" -gt 1
then
local F=$1
shift
printf "$@" | eval "$GIT_TEST_CMP" '"$F"' -
else
eval "$GIT_TEST_CMP" '"$1"' -
fi
}
to allow writing simpler tests like:
--- a/t/t3204-branch-name-interpretation.sh
+++ b/t/t3204-branch-name-interpretation.sh
@@ -142,8 +142,7 @@ test_expect_success 'edit-description via @{-1}' '
EDITOR=./editor git branch --edit-description @{-1} &&
test_must_fail git config branch.non-desc-branch.description &&
git config branch.desc-branch.description >actual &&
- printf "Branch description\n\n" >expect &&
- test_cmp expect actual
+ test_cmp_str actual "Branch description\n\n"
'
--- a/t/t3204-branch-name-interpretation.sh
+++ b/t/t3204-branch-name-interpretation.sh
@@ -142,8 +142,10 @@ test_expect_success 'edit-description via @{-1}' '
EDITOR=./editor git branch --edit-description @{-1} &&
test_must_fail git config branch.non-desc-branch.description &&
git config branch.desc-branch.description >actual &&
- printf "Branch description\n\n" >expect &&
- test_cmp expect actual
+ test_cmp_str actual <<-\EOF
+ Branch description
+
+ EOF
'
My doubts are that maybe this can induce to some bad usages, is
unusable in some systems, it has already been explored and discarded,
using files gives the diff with nice names not "-",...
Maybe this needs a new RFC thread. I dunno.
Thanks for your comments and explanations.
next prev parent reply other threads:[~2022-10-08 23:28 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-05 14:34 [PATCH 0/2] branch: support for at-refs like @{-1} in --edit-description, --set-upstream-to and --unset-upstream Rubén Justo via GitGitGadget
2022-09-05 14:34 ` [PATCH 1/2] branch: refactor edit_description command switch case Rubén Justo via GitGitGadget
2022-09-05 14:34 ` [PATCH 2/2] branch: support for at-refs like @{-1} Rubén Justo via GitGitGadget
2022-09-07 9:45 ` [PATCH v2 0/2] branch: support for shortcuts like @{-1}, completed Rubén Justo
2022-09-07 9:52 ` [PATCH v2 1/2] branch: refactor "edit_description" code path Rubén Justo
2022-09-07 20:25 ` Junio C Hamano
2022-09-07 21:24 ` Rubén Justo
2022-09-08 4:32 ` Rubén Justo
2022-09-07 9:53 ` [PATCH v2 2/2] branch: support for shortcuts like @{-1} completed Rubén Justo
2022-09-08 4:47 ` [PATCH v3 0/2] branch: support for shortcuts like @{-1}, completed Rubén Justo
2022-09-08 4:51 ` [PATCH v3 1/2] branch: refactor "edit_description" code path Rubén Justo
2022-09-08 20:57 ` [PATCH] branch: error codes for "edit_description" Rubén Justo
2022-09-08 21:45 ` Junio C Hamano
2022-09-08 4:53 ` [PATCH v3 2/2] branch: support for shortcuts like @{-1} completed Rubén Justo
2022-10-08 1:00 ` [PATCH v4] branch: support for shortcuts like @{-1}, completed Rubén Justo
2022-10-08 3:17 ` Eric Sunshine
2022-10-08 4:23 ` Junio C Hamano
2022-10-08 7:07 ` Rubén Justo
2022-10-08 7:23 ` Eric Sunshine
2022-10-08 9:12 ` Rubén Justo
2022-10-08 17:10 ` Eric Sunshine
2022-10-08 17:46 ` Junio C Hamano
2022-10-08 20:48 ` Rubén Justo
2022-10-08 23:28 ` Rubén Justo [this message]
2022-10-09 6:46 ` Eric Sunshine
2022-10-09 19:33 ` Junio C Hamano
2022-10-09 22:27 ` Rubén Justo
2022-10-08 4:17 ` Junio C Hamano
2022-10-08 9:04 ` Rubén Justo
2022-10-08 22:32 ` [PATCH v5] " Rubén Justo
2022-10-09 5:37 ` Junio C Hamano
2022-10-09 19:11 ` Junio C Hamano
2022-10-09 21:26 ` Rubén Justo
2022-10-10 0:38 ` Junio C Hamano
2022-10-10 6:05 ` Rubén Justo
2022-10-10 16:55 ` Junio C Hamano
2022-10-10 18:08 ` Rubén Justo
2022-10-10 23:24 ` [PATCH v6] " Rubén Justo
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=32e4f8cf-696c-317d-236b-0f64c1398a01@gmail.com \
--to=rjusto@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=sunshine@sunshineco.com \
/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).