From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Thomas Gummerer <t.gummerer@gmail.com>
Cc: Jonathan Chang <ttjtftx@gmail.com>,
Git Mailing List <git@vger.kernel.org>,
Christian Couder <christian.couder@gmail.com>,
Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [GSoC][PATCH v3 3/3] t0000: use test_line_count instead of wc -l
Date: Mon, 18 Mar 2019 08:36:07 +0100 [thread overview]
Message-ID: <87ftrkab2w.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <20190317200609.GA1216@hank.intra.tgummerer.com>
On Sun, Mar 17 2019, Thomas Gummerer wrote:
> On 03/17, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Sun, Mar 17 2019, Jonathan Chang wrote:
>>
>> > Signed-off-by: Jonathan Chang <ttjtftx@gmail.com>
>> > ---
>> > t/t0000-basic.sh | 7 +++----
>> > 1 file changed, 3 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
>> > index 47666b013e..3de13daabe 100755
>> > --- a/t/t0000-basic.sh
>> > +++ b/t/t0000-basic.sh
>> > @@ -1136,8 +1136,8 @@ test_expect_success 'git commit-tree omits duplicated parent in a commit' '
>> > parent=$(sed -n -e "s/^parent //p" -e "/^author /q" actual | sort -u) &&
>> > test "z$commit0" = "z$parent" &&
>> > git show --pretty=raw $commit2 >actual &&
>> > - numparent=$(sed -n -e "s/^parent //p" -e "/^author /q" actual | wc -l) &&
>> > - test $numparent = 1
>> > + sed -n -e "s/^parent //p" -e "/^author /q" actual >parents &&
>> > + test_line_count = 1 parents
>> > '
>> >
>> > test_expect_success 'update-index D/F conflict' '
>> > @@ -1146,8 +1146,7 @@ test_expect_success 'update-index D/F conflict' '
>> > mv tmp path2 &&
>> > git update-index --add --replace path2 path0/file2 &&
>> > git ls-files path0 >actual &&
>> > - numpath0=$(wc -l <actual) &&
>> > - test $numpath0 = 1
>> > + test_line_count = 1 actual
>> > '
>>
>> ...of course reading this series in sequence I find that 50% of my
>> suggestions for 2/3 are then done in this patch... :)
>
> Indeed. I think doing this in a separate patch is a good idea, as it
> makes the previous patch slightly easier to review imho. But I think
> something to take away from this for Jonathan would be that this
> should have been described in the commit message of the previous
> commit. Maybe something like
>
> This commit doesn't make any additional simplifications, such as
> using the test_line_count function for counting the lines in the
> output. These simplifications will be made in a subsequent commit.
>
> in addition to the existing commit message would have helped save a
> bit of review effort.
FWIW I chuck this up to just my blindness / expedience in reading the
thing.
No objections to changing this, but I don't think it's the fault of a
commit message if someone reading it doesn't get an explanation for a
future unrelated improvement.
The times when a commit should have such an explanation are cases like
e.g. introducing a function that's not used yet to make a subsequent
commit smaller, or other such cases where the change is incomplete in
some way.
next prev parent reply other threads:[~2019-03-18 7:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-17 15:23 [GSoC][PATCH v3 0/3] Avoid using pipes Jonathan Chang
2019-03-17 15:23 ` [GSoC][PATCH v3 1/3] t0000: fix indentation Jonathan Chang
2019-03-17 15:23 ` [GSoC][PATCH v3 2/3] t0000: avoid using pipes Jonathan Chang
2019-03-17 16:47 ` Ævar Arnfjörð Bjarmason
2019-03-24 11:26 ` jonathan chang
2019-03-24 19:04 ` Ævar Arnfjörð Bjarmason
2019-03-17 15:23 ` [GSoC][PATCH v3 3/3] t0000: use test_line_count instead of wc -l Jonathan Chang
2019-03-17 16:48 ` Ævar Arnfjörð Bjarmason
2019-03-17 20:06 ` Thomas Gummerer
2019-03-18 7:36 ` Ævar Arnfjörð Bjarmason [this message]
2019-03-18 8:15 ` Junio C Hamano
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ftrkab2w.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=sunshine@sunshineco.com \
--cc=t.gummerer@gmail.com \
--cc=ttjtftx@gmail.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.
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).