Re: [PATCH] rev-parse: add option for absolute or relative path formatting
- From
brian m. carlson <sandals@crustytoothpaste.net>
- Date
- Sep 9, 2020, 22:31 UTC
- Message-ID
- <20200909223151.GI241078@camp.crustytoothpaste.net>
- In-Reply-To
- <nycvar.QRO.7.76.6.2009090513300.54@tvgsbejvaqbjf.bet>
On 2020-09-09 at 03:23:32, Johannes Schindelin wrote:
Show 24 quoted lines
> 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.
Show 20 quoted lines
> > 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