git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: "SZEDER Gábor" <szeder.dev@gmail.com>
Cc: git@vger.kernel.org, Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH] rev-parse: add option for absolute or relative path formatting
Date: Fri, 11 Sep 2020 00:03:15 +0000
Message-ID: <20200911000315.GL241078@camp.crustytoothpaste.net> (raw)
In-Reply-To: <20200910151935.GA5265@szeder.dev>

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

On 2020-09-10 at 15:19:35, SZEDER Gábor wrote:
> Well, on first sight it seems nice that scripts have to specify
> '--path-format=absolute' only once when querying multiple paths at
> once, though on second thought no prudent script would query multiple
> paths at once, because they might contain newlines.

We do that in Git LFS at the cost of not handling paths with newlines
because calling out to Git multiple times is expensive, very especially
on Windows.  Of course, Windows doesn't allow newlines in paths, but it
seems silly to have two different code paths for the same thing,
especially on top of the different paths we have for versions of Git
with and without worktrees (and therefore --git-common-dir).

If you're writing a script, you're not expecting great performance (or
you wouldn't be writing shell), so it's less of a problem and you can
actually afford the cost of being a little more correct.

I think if we wanted to prudently handle paths with newlines, we'd want
to add a -z option to rev-parse (think about the case in shell where the
path ends with a trailing newline).  I may get around to that at some
point, but anyone is welcome to pick it up before me.

> Yeah, I think I found trouble that way, too.  I wonder whether
> '--path-format=relative' is really worth having, though.  Clearly
> there's a need for absolute paths, because getting relative paths
> causes difficulties for some scripts; I described one such use case in
> a2f5a87626 (rev-parse: add '--absolute-git-dir' option, 2017-02-03),
> and you just ran into another with Git LFS.  However, is there really
> a use case that requires relative paths, because an absolute path
> would cause similar difficulties?  I couldn't come with any.

The only case I can come up with is possibly wanting to know if a path
is within another path, or if it's outside, and doing that with relative
paths may be easier.

> So perhaps it would be sufficient to introduce only
> '--path-format=absolute' (or equivalent) for now, and add a relative
> path variant only when there will be an actual compelling reason to do
> so.  And that would save you from the pain of addressing these bugs
> shown above.

I'll consider it when I do my reroll, which will probably be this
weekend.
-- 
brian m. carlson: Houston, Texas, US

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

  reply	other threads:[~2020-09-11  0:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-08 18:50 brian m. carlson
2020-09-09  3:23 ` Johannes Schindelin
2020-09-09 22:31   ` brian m. carlson
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 [this message]
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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20200911000315.GL241078@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=szeder.dev@gmail.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

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for the project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git