From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
Mark Amery <markrobertamery@gmail.com>,
git@vger.kernel.org
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: <nycvar.QRO.7.76.6.2105051528030.50@tvgsbejvaqbjf.bet> (Johannes Schindelin's message of "Wed, 5 May 2021 15:51:14 +0200 (CEST)")
Johannes Schindelin <Johannes.Schindelin@gmx.de> 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
functions.
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.
next prev parent 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:
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=xmqqeeek3de1.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=markrobertamery@gmail.com \
--cc=sandals@crustytoothpaste.net \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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).