mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Johannes Schindelin <>
Cc: "brian m. carlson" <>,
	Mark Amery <>,
Subject: Re: Bug: Changing folder case with `git mv` crashes on case-insensitive file system
Date: Thu, 06 May 2021 09:38:14 +0900	[thread overview]
Message-ID: <xmqqeeek3de1.fsf@gitster.g> (raw)
In-Reply-To: <> (Johannes Schindelin's message of "Wed, 5 May 2021 15:51:14 +0200 (CEST)")

Johannes Schindelin <> writes:

> So _if_ we need that file ID information, I would be very much in favor of
> introducing a proper abstraction, where differentiate between the
> intention (think `get_inode(const char *path)`) from the
> platform-dependent implementation detail (think `lstat()`, `CreateFile()`
> and `GetFileInformationByHandle()`).

I agree in principle.  Essentially, we need to

 (1) examine all calls to lstat(2) we make in our codebase, and find
     out what members of "stat" are really used out of the result
     for each callsite.  This will be different from caller to
     caller (some callers may want only ino, other callers may want
     ino, size, and mtime, etc.), and we would learn that there are
     N patterns.

 (2) write N abstracted helper functions (or a single helper that
     takes const char *path, struct stat *, and an enum to tell
     which one of N patterns this call is about).

 (3) replace each lstat(2) call with one of these N abstract helper

get_inode() might be one of these N functions, but what is important
is that the current callers that want ino and something else should
not be penalized by making two separte calls get_inode() and
get_other_things(), which, when done naively, would result in two
lstat(2) calls.

  reply	other threads:[~2021-05-06  0:38 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
2021-05-04 11:20     ` brian m. carlson
2021-05-05 13:51       ` Johannes Schindelin
2021-05-06  0:38         ` Junio C Hamano [this message]
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=xmqqeeek3de1.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).