git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Torsten Bögershausen" <tboegi@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Mark Mentovai <mark@chromium.org>,
	Git Development <git@vger.kernel.org>,
	Eric Sunshine <sunshine@sunshineco.com>,
	Derrick Stolee <stolee@gmail.com>
Subject: Re: [PATCH v2] t: run tests from a normalized working directory
Date: Sat, 31 May 2025 07:46:18 +0200	[thread overview]
Message-ID: <20250531054618.GA30443@tb-raspi4> (raw)
In-Reply-To: <xmqqfrgmhep3.fsf@gitster.g>

On Thu, May 29, 2025 at 10:04:24PM -0700, Junio C Hamano wrote:
> Torsten Bögershausen <tboegi@web.de> writes:
> 
> > On Wed, May 28, 2025 at 04:17:37PM -0400, Mark Mentovai wrote:
> >
> > The problem is well described, thanks for that.
> > However, different words and terms are used for the same thing:
> >   "normalized working directory" (which is easy to confuse
> >     with normalized working tree where CRLF-LF conversion had been
> >     done and clean filters applied.
> >   "pathname canonicalization"
> >   "canonical absolute path"
> >   "normalized path"
> > ... and that is done in "strbuf_realpath()"
> >
> > May be the word normalized can be replaced here ?
> > Starting with the head line, how about this:
> > t: run tests from an absolute path
> >
> > And later in the text:
> > use "absolute path" instead of "normalized path" ?
> 
> Thanks for a careful reading.  When I read the log message for the
> first time, it did not bother me too much that it said canonicalize
> and normalize interchangeably, and the two verbs still do not bother
> me terribly.  I agree with you that clearly describing what the
> canonicalization rules do (i.e. fully resolving symbolic links to
> make the path absolute) very good idea, but I think the last
> sentence of the first paragraph does a good job at it already.
> 
> Can you offer a rewrite along the lines you suggest so that we can
> compare?  I personally felt that what Mark gave us, albeit a bit on
> the more verbose and repetitive side, were written clearly enough.
> 
> Thanks.

Here is an attempt to do so.
The word canonical has been removed.
After reading the help for
'pwd -P' and 'cd -P'
"absolute" is replaced by "physical".
A matter of taste.
If absolute is more used here in Git, I am fine with any.

==================================================
t: run 7900 tests from the physical working directory

Some tests make git perform actions that produce observable pathnames,
and have expectations on those paths. Tests run with $HOME set to a
$TRASH_DIRECTORY, and with their working directory the same
$TRASH_DIRECTORY, although these paths are physical identical, they do
not observe the same pathname normalization rules and thus might not
be represented by strings that compare equal. In particular, no pathname
normalization is applied to $TRASH_DIRECTORY or $HOME, while tests
change their working directory with `cd -P` which resolves symbolic links
returning the physical path.

t7900's macOS maintenance tests (which are not limited to running on
macOS) have an expectation on a path that `git maintenance` forms by
using abspath.c strbuf_realpath() to resolve the physical path
based on $HOME. When t7900 runs from a working directory that contains
symbolic links in its pathname, $HOME will also contain symbolic links,
which `git maintenance` resolves but the test's expectation does not,
causing a test failure.

Align $TRASH_DIRECTORY and $HOME with the physical path as used for
the working directory by resetting them to match the working directory
after it's established by `cd -P`. With all paths in agreement and
symbolic links resolved, pathname expectations can be set and met based
on string comparison without regard to external environmental factors
such as the presence of symbolic links in a path.

  reply	other threads:[~2025-05-31  5:46 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-23 19:37 [PATCH] t7900: use pwd -P in macOS maintenance test Mark Mentovai
2025-05-23 20:08 ` Eric Sunshine
2025-05-23 20:42   ` Junio C Hamano
2025-05-23 21:24     ` Eric Sunshine
2025-05-23 21:51       ` Junio C Hamano
2025-05-24  4:39         ` Mark Mentovai
2025-05-27 17:19           ` Junio C Hamano
2025-05-23 20:43   ` Mark Mentovai
2025-05-23 21:36     ` Eric Sunshine
2025-05-28 20:17 ` [PATCH v2] t: run tests from a normalized working directory Mark Mentovai
2025-05-28 23:08   ` Torsten Bögershausen
2025-05-30  5:04     ` Junio C Hamano
2025-05-31  5:46       ` Torsten Bögershausen [this message]
2025-06-01 16:38         ` Junio C Hamano
2025-06-02 16:08           ` Mark Mentovai
2025-06-02 21:32             ` Junio C Hamano
2025-06-03  5:02               ` Torsten Bögershausen
2025-06-03 13:15                 ` Mark Mentovai
2025-06-03 18:22                   ` 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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250531054618.GA30443@tb-raspi4 \
    --to=tboegi@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mark@chromium.org \
    --cc=stolee@gmail.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).