From: Rudy Rigot <rudy.rigot@gmail.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: "Rudy Rigot via GitGitGadget" <gitgitgadget@gmail.com>,
git@vger.kernel.org, "Jeff Hostetler" <git@jeffhostetler.com>,
"Taylor Blau" <me@ttaylorr.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Derrick Stolee" <derrickstolee@github.com>
Subject: Re: [PATCH v4] status: long status advice adapted to recent capabilities
Date: Thu, 10 Nov 2022 11:47:29 -0600 [thread overview]
Message-ID: <CANaDLWKR93_qfOkT6_u_qvUYZqjAZ_z_YXtzDFHXB+RY8nZhTg@mail.gmail.com> (raw)
In-Reply-To: <CAPig+cTFRV=Np2oV5QJDpmwOwBaTVnjmAqcz-Ny7hCi6PexQUA@mail.gmail.com>
Oh, thanks, all of this helps a ton. I know exactly what to do about
those two things now.
On Thu, Nov 10, 2022 at 11:30 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
>
> On Thu, Nov 10, 2022 at 12:02 PM Rudy Rigot <rudy.rigot@gmail.com> wrote:
> > > the <<- operator allows you to indent the here-doc body
> > > (with TABs, not spaces), so you can align the body with the rest of
> > > the code
> >
> > Unfortunately, that's how I had done it first, but since some of those
> > lines are blank, the test code had lines just made of "<tab><tab>" and
> > nothing else, which made the check-whitespace check fail. I considered
> > replacing empty line with something on the fly with sed (like just an
> > "x" character for instance), but this felt hacky and brittle (in the
> > unlikely case where an actual "x" would find itself genuinely lost in
> > the middle of that output, the test would mistakenly pass). I went
> > with the solution I'm presenting here because the readability
> > downsides of missing that indentation felt less bad. Definitely
> > willing to be convinced though.
>
> Okay, I see what you're getting at. Fortunately, there is a simple
> solution as long as those lines are truly blank as emitted by `git
> status`: just leave the blank lines completely blank in the here-doc
> body (don't bother inserting a TAB on the blank line). This should
> product the exact output you want:
>
> cat >../expected <<-\EOF &&
> On branch test
>
> No commits yet
> ...
> EOF
>
> Although it should not be needed here, the `sed` approach is generally
> fine, and we use it often enough in tests, though usually with a more
> uncommon letter such as "Q". See, for instance, the q_to_nul(),
> q_to_tab(), etc. functions in t/test-lib-functions.sh.
>
> > > I presume the reason you're escaping the "trash" directory is because
> > > you don't want these untracked "actual" and "expected" files to
> > > pollute the `git status` output you're testing?
> >
> > You are presuming right! The test was being flappy in CI runs before I
> > changed this, which I found used as a solution in other
> > git-status-related tests currently in the codebase. I'm not familiar
> > with the trash directory approach, but I'll figure it out.
>
> Each test script is run in a temporary "trash" directory which gets
> thrown away when the script finishes. We want tests to constrain
> themselves to the trash directory so they don't inadvertently destroy
> a user's files outside the directory.
>
> I see what you mean about some existing status-related tests using
> files such as "../actual" and "../expect". It's not at all obvious in
> a lot of those cases but they are safe[*] because those tests have
> already cd'd into a subdirectory of the "trash" directory, thus
> "../actual" is referring to the "trash" directory itself, hence the
> tests do constrain themselves to "trash".
>
> Anyhow, I suspect that crafting a custom .gitignore file in the test
> setup should satisfy this particular case and allow "actual" and
> "expected" to reside in the "trash" directory itself without mucking
> up `git status` output.
>
> [*] Unfortunately, some of those scripts are poorly structured because
> they `cd` around between tests, which can leave CWD in an unexpected
> state if some test fails and subsequent tests expect CWD to be
> somewhere other than where it was left by the failed test. These days,
> we only allow tests to `cd` within a subshell so that CWD is restored
> automatically whether the test itself succeeds or fails. So, this is
> safe:
>
> test_expect_success 'title' '
> do something &&
> mkdir foo &&
> (
> cd foo &&
> do something else >../actual &&
> )
> grep foo actual
> '
next prev parent reply other threads:[~2022-11-10 17:47 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-15 13:04 [PATCH] fsmonitor: long status advice adapted to the fsmonitor use case Rudy Rigot via GitGitGadget
2022-10-15 13:08 ` Rudy Rigot
2022-10-17 15:39 ` Jeff Hostetler
2022-10-17 16:59 ` Rudy Rigot
2022-10-20 12:56 ` Jeff Hostetler
2022-10-20 20:17 ` Rudy Rigot
2022-10-24 14:55 ` Jeff Hostetler
2022-10-29 0:06 ` [PATCH v2] status: long status advice adapted to recent capabilities Rudy Rigot via GitGitGadget
2022-11-02 19:45 ` Jeff Hostetler
2022-11-02 20:34 ` Rudy Rigot
2022-11-02 23:59 ` Taylor Blau
2022-11-03 14:28 ` Rudy Rigot
2022-11-04 8:52 ` Ævar Arnfjörð Bjarmason
2022-11-04 15:33 ` Rudy Rigot
2022-11-04 21:38 ` Taylor Blau
2022-11-02 21:27 ` [PATCH v3] " Rudy Rigot via GitGitGadget
2022-11-04 21:40 ` Taylor Blau
2022-11-07 20:02 ` Derrick Stolee
2022-11-07 23:19 ` Taylor Blau
2022-11-15 16:38 ` Jeff Hostetler
2022-11-07 20:01 ` Derrick Stolee
2022-11-07 20:20 ` Eric Sunshine
2022-11-07 20:31 ` Rudy Rigot
2022-11-10 4:46 ` [PATCH v4] " Rudy Rigot via GitGitGadget
2022-11-10 5:42 ` Eric Sunshine
2022-11-10 17:01 ` Rudy Rigot
2022-11-10 17:30 ` Eric Sunshine
2022-11-10 17:47 ` Rudy Rigot [this message]
2022-11-10 20:04 ` [PATCH v5] " Rudy Rigot via GitGitGadget
2022-11-15 16:39 ` Jeff Hostetler
2022-11-15 16:42 ` Rudy Rigot
2022-11-15 17:26 ` Eric Sunshine
2022-11-15 17:45 ` Rudy Rigot
2022-11-15 18:06 ` Eric Sunshine
2022-11-15 18:08 ` Rudy Rigot
2022-11-15 21:19 ` [PATCH v6] " Rudy Rigot via GitGitGadget
2022-11-21 5:06 ` Eric Sunshine
2022-11-21 15:54 ` Rudy Rigot
2022-11-21 16:17 ` Eric Sunshine
2022-11-22 16:52 ` Rudy Rigot
2022-11-22 17:18 ` Eric Sunshine
2022-11-22 17:24 ` Eric Sunshine
2022-11-22 17:29 ` Rudy Rigot
2022-11-22 17:40 ` Eric Sunshine
2022-11-22 18:07 ` Eric Sunshine
2022-11-22 19:19 ` Rudy Rigot
2022-11-22 19:48 ` Eric Sunshine
2022-11-22 16:59 ` [PATCH v7] status: modernize git-status "slow untracked files" advice Rudy Rigot via GitGitGadget
2022-11-22 22:07 ` [PATCH v8] " Rudy Rigot via GitGitGadget
2022-11-25 4:58 ` Junio C Hamano
2022-11-29 15:21 ` Rudy Rigot
2022-11-30 0:51 ` Rudy Rigot
2022-11-30 0:52 ` [PATCH v9] " Rudy Rigot via GitGitGadget
2022-12-01 6:48 ` Junio C Hamano
2022-12-01 15:16 ` Rudy Rigot
2022-12-01 22:45 ` Junio C Hamano
2022-12-01 22:57 ` Rudy Rigot
2023-05-11 5:17 ` [PATCH v8] " Eric Sunshine
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=CANaDLWKR93_qfOkT6_u_qvUYZqjAZ_z_YXtzDFHXB+RY8nZhTg@mail.gmail.com \
--to=rudy.rigot@gmail.com \
--cc=avarab@gmail.com \
--cc=derrickstolee@github.com \
--cc=git@jeffhostetler.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=me@ttaylorr.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.
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).