mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: "brian m. carlson" <>
Cc: Mark Amery <>,
Subject: Re: Bug: Changing folder case with `git mv` crashes on case-insensitive file system
Date: Tue, 04 May 2021 12:46:12 +0900	[thread overview]
Message-ID: <xmqqfsz36u0r.fsf@gitster.g> (raw)
In-Reply-To: <> (brian m. carlson's message of "Mon, 3 May 2021 22:58:14 +0000")

"brian m. carlson" <> writes:

> Yeah, this is because your operating system returns EINVAL in this case.
> POSIX specifies EINVAL when you're trying to make a directory a
> subdirectory of itself.  Which, I mean, I guess is a valid
> interpretation here, but it of course makes renaming the path needlessly
> difficult.
> ...
> I suspect part of the problem here is two fold: on macOS we can't
> distinguish an attempt to rename the path due to it folding or
> canonicalizing to the same thing from a real attempt to move an actual
> directory into itself.  The latter would be a problem we'd want to
> report, and the former is not.  Unfortunately, detecting this is
> difficult because that means we'd have to implement the macOS
> canonicalization algorithm in Git and we don't want to do that.

I agree we'd probably need to resort to macOS specific hack (like we
have NFS or Coda specific hacks), but it may not be too bad.

After seeing EINVAL, we can lstat src 'foo' and dst 'FOO', and
realize that both are directories and have the same st_dev/st_ino,
which should be fairly straightforward, no?

For that, we do not exactly have to depend on any part of macOS-ism;
we do depend on the traditional "within the same device, inum is a
good way to tell if two filesystem entities are the same".

The (mis)design of "git mv a b c d ... DST" that turns the request
into "mv a DST/a && mv b DST/b && ..." too early may make the
fallback behaviour a bit cumbersome to implement (mainly, we need to
strip out the '/foo' part out of the failing dst FOO/foo to get the
real destination directory 'FOO' the user gave us, before checking
with that lstat dance), but since it is an error codepath, we can be
as inefficient as we like, as long as we are correct ;-)

  reply	other threads:[~2021-05-04  3:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-03 17:25 Bug: Changing folder case with `git mv` crashes on case-insensitive file system Mark Amery
2021-05-03 22:58 ` brian m. carlson
2021-05-04  3:46   ` Junio C Hamano [this message]
2021-05-04 11:20     ` brian m. carlson
2021-05-05 13:51       ` Johannes Schindelin
2021-05-06  0:38         ` Junio C Hamano
2021-05-04 15:19 ` Torsten Bögershausen
2021-05-05  0:23   ` Junio C Hamano
2021-05-05  2:12     ` brian m. carlson
2021-05-06  4:34     ` Torsten Bögershausen
2021-05-06  9:12       ` Mark Amery
2021-05-06 13:11         ` Bagas Sanjaya
2021-05-06 14:53         ` Torsten Bögershausen
2021-05-06 21:03         ` Junio C Hamano

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:

  List information:

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

  git send-email \
    --in-reply-to=xmqqfsz36u0r.fsf@gitster.g \ \ \ \ \

* 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.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).