All of lore.kernel.org
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] rev-parse: add option for absolute or relative path formatting
Date: Wed, 9 Sep 2020 22:31:51 +0000	[thread overview]
Message-ID: <20200909223151.GI241078@camp.crustytoothpaste.net> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.2009090513300.54@tvgsbejvaqbjf.bet>

[-- Attachment #1: Type: text/plain, Size: 2791 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

  reply	other threads:[~2020-09-09 22:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-08 18:50 [PATCH] rev-parse: add option for absolute or relative path formatting brian m. carlson
2020-09-09  3:23 ` Johannes Schindelin
2020-09-09 22:31   ` brian m. carlson [this message]
2020-09-09 14:51 ` SZEDER Gábor
2020-09-09 22:23   ` brian m. carlson
2020-09-10 15:19     ` SZEDER Gábor
2020-09-11  0:03       ` brian m. carlson
2020-11-04 22:16 ` Jonathan Nieder
2020-11-05  3:11   ` brian m. carlson
2020-11-06  0:51     ` Jonathan Nieder
2020-11-06  1:57       ` brian m. carlson

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=20200909223151.GI241078@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.