Torsten Bögershausen <tboegi@xxxxxx> writes:
> 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.
It is OK as long as we are locally consistent. I do think inside
our codebase it seems we use "absolute" more, but the change in
question is about use of "-P" option, which certainly was taken from
"physical", in our test scripts, so I am OK with your description
below to use that word.
If somebody really cared (and I don't), we may want to pick a single
word among physical, absolute, and real, but the only thing is that
we are using them interchangeably, so as long as we make it clear
(e.g. perhaps strbuf_realpath() and the underlying helper functions
that are used by it may have a comment or two that says that we use
these three words interchangeably to our developers), it would be
good enough.
> ==================================================
> 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.
"physical identical"? I think the problem is $HOME and $TRASH are
the same but not physically normalized, which means "cd $HOME &&
pwd", "cd $HOME && pwd -P" and "cd -P $HOME && pwd" can give
different results from these two variables. How about replacing the
latter half of the above with something much simpler, like this?
... although HOME and TRASH_DIRECTORY have identical values, the
physical path to it (i.e. what "cd $HOME && pwd -P" reports) may
be different.
> 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.
