On 2020-09-09 at 03:23:32, Johannes Schindelin wrote:
> On Tue, 8 Sep 2020, brian m. carlson wrote:
> 
> > git rev-parse has several options which print various paths.  Some of
> > these paths are printed relative to the current working directory, and
> > some are absolute.
> >
> > Normally, this is not a problem, but there are times when one wants
> > paths entirely in one format or another.  This can be done trivially if
> > the paths are canonical, but canonicalizing paths is not possible on
> > some shell scripting environments which lack realpath(1) and also in Go,
> > which lacks functions that properly canonicalize paths on Windows.
> >
> > To help out the scripter, let's provide an option which turns most of
> > the paths printed by git rev-parse to be either relative to the current
> > working directory or absolute and canonical.  Document which options are
> > affected and which are not so that users are not confused.
> >
> > This approach is cleaner and tidier than providing duplicates of
> > existing options which are either relative or absolute.
> >
> > Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
> > ---
> 
> Nicely explained and implemented.

Thanks.

> > This impetus for this patch is Git LFS, which is written in Go.  Go
> > lacks a cross-platform way to canonicalize paths in the same way that
> > Git does, so when Git produces relative paths, such as in some cases
> > with --git-common-dir, we end up with problems when users are doing
> > things with unusual paths on Windows, such as when using SUBST or
> > OneDrive or various other edge cases.  Go upstream does not appear eager
> > to address this problem.
> >
> > The obvious solution to this is to have Git canonicalize all paths, and
> > rather than adding yet another one-off, I decided to implement a more
> > generic solution.  This can also be valuable for shell scripting
> > environments which lack realpath(1) (e.g. macOS, IIRC).
> >
> > Dscho CC'd for visibility into how this will work on Windows.
> 
> On Windows, at least in the version from git-for-windows/git,
> `strbuf_realpath()` uses the Win32 API function
> `GetFinalPathNameByHandleW()` to canonicalize paths (whenever possible),
> meaning that the `subst` issue you mentioned above will be addressed
> adequately.

Yeah, I looked into the function Git for Windows used, and it's also
used by Rust's std::path::canonicalize, so I think there's wide
agreement that this is the right function to be using here.

I think for _most_ of our cases, it matters a little less how we're
handling paths than that we're handling them consistently, but if we can
fix all of the cases, not just most, that's preferable.
-- 
brian m. carlson: Houston, Texas, US