lockfile: add case insensitive filesystem note
PATCH 1/1 lockfile: add case insensitive filesystem note
From: Alan Da Costa <[email protected]>
* Add note of case insensitive client filesystems may error due to a lock on a case variant ref to more quickly identify failure in fetch/pull
---
lockfile: add case insensitive filesystem note
When running git fetch or git pull on a case insensitive filesystem (e.g., default macOS), if multiple case variants of the same remote ref exist (often after a case-only rename), both variant locks map to the same on-disk path. When a local update is required, Git creates a lock for the first variant and then attempts to lock the second, which collides with the same lock file, so an “existing lock” error is reported. The underlying issue is mixed-case refs; resolve it by consolidating the remote to a single-case variant and update local refs accordingly.
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2053%2Fadacosta%2Flockfile-add-case-insensitive-filesystem-note-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2053/adacosta/lockfile-add-case-insensitive-filesystem-note-v1
Pull-Request: https://github.com/git/git/pull/2053
lockfile.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
lockfile.c +4 -1
@@ -156,7 +156,10 @@ void unable_to_lock_message(const char *path, int err, struct strbuf *buf)"an editor opened by 'git commit'. Please make sure all processes\n" "are terminated then try again. If it still fails, a git process\n" "may have crashed in this repository earlier:\n" - "remove the file manually to continue."), +"remove the file manually to continue.\n\n" +"On case insensitive client filesystems, multiple mixed-case refs will resolve\n" +"to the same lock file, possibly causing this error. If so, ensure your remote\n" + "refs have a single case variant."), absolute_path(path), strerror(err)); }else strbuf_addf(buf, _("Unable to create '%s.lock': %s"),
base-commit: ab427cd991100e94792fce124b0934135abdea4b
Signature · 1 line
gitgitgadget
Quoted 4 lines · Alan Da Costa via GitGitGadget
From: Alan Da Costa <[email protected]>
* Add note of case insensitive client filesystems may error due to a lock on a case variant ref to more quickly identify failure in fetch/pull
This does not have to be a single-item bulletted list. Please lose the leading "* " from the first line, and " " from the second line, and finish the whole sentence with a full-stop "."
Quoted 10 lines
Signed-off-by Alan Da Costa <[email protected]>---
When running git fetch or git pull on a case insensitive filesystem (e.g., default macOS), if multiple case variants of the same remote ref exist (often after a case-only rename), both variant locks map to the same on-disk path. When a local update is required, Git creates a lock for the first variant and then attempts to lock the second, which collides with the same lock file, so an “existing lock” error is reported.
And the message update may help unconfusing the user who gets this error, which is a good idea. Thanks for working on this.
Quoted 3 lines
The underlying issue is mixed-case refs; resolve it by consolidating the remote to a single-case variant and update local refs accordingly.
This does not seem to match anything the patch does, though ;-)
Quoted 13 lines
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2053%2Fadacosta%2Flockfile-add-case-insensitive-filesystem-note-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2053/adacosta/lockfile-add-case-insensitive-filesystem-note-v1
Pull-Request: https://github.com/git/git/pull/2053lockfile.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)lockfile.c +0
-0
lockfile.c void unable_to_lock_message(const char *path, int err, struct strbuf *buf) · line 163
Quoted 9 lines
lockfile.c +4
-1@@ -156,7 +156,10 @@ void unable_to_lock_message(const char *path, int err, struct strbuf *buf)"an editor opened by 'git commit'. Please make sure all processes\n" "are terminated then try again. If it still fails, a git process\n" "may have crashed in this repository earlier:\n" - "remove the file manually to continue."), +"remove the file manually to continue.\n\n" +"On case insensitive client filesystems, multiple mixed-case refs will resolve\n" +"to the same lock file, possibly causing this error. If so, ensure your remote\n" + "refs have a single case variant."), absolute_path(path), strerror(err));
The two lines in the new part of the message seem to be longer than usual by two words or so. Can you line wrap to balance?
The error is about our "local" filesystem, isn't it? If you do not have control over what the remote does, you have no recourse. If using the reftable backend on the local end work around the local filesystem's case insensitivity, that would be a better suggestion to give that such a user can actually act on.
In any case, wouldn't it make more sense to do this change conditionally by looking at the value of the ignore_case global (which in turn came from the core.ignorecase setting in .git/config when the repository was created by probing the filesystem capabilities)? If you get this error and you are on a case sensitive system, the additional hints will lead the user to a wild goose chase.
Thanks.
Quoted 10 lines · Alan Da Costa via GitGitGadget
From: Alan Da Costa <[email protected]>
When running git fetch or git pull on a case insensitive filesystem (e.g., default macOS), if multiple case variants of the same remote ref exist (often after a case-only rename), both variant locks map to the same on-disk path. When a local update is required, Git creates a lock for the first variant and then attempts to lock the second, which collides with the same lock file, so an “existing lock” error is reported. The underlying issue is mixed-case refs; resolve it by consolidating the remote to a single-case variant and update local refs accordingly.
Are you aware of Karthik's recent patch series at [1]? It looks like this addresses your exact problem in a more direct way, and the resulting error messages that we have in that patch series also give a bit more advice for how to handle the situation.
The patch series wasn't merged yet, but will probably be merged soon. Could you maybe test that series and say whether it addresses your need?
Thanks!
Patrick
Quoted 12 lines · Patrick Steinhardt
Quoted 10 lines · Alan Da Costa via GitGitGadget
From: Alan Da Costa <[email protected]>
When running git fetch or git pull on a case insensitive filesystem (e.g., default macOS), if multiple case variants of the same remote ref exist (often after a case-only rename), both variant locks map to the same on-disk path. When a local update is required, Git creates a lock for the first variant and then attempts to lock the second, which collides with the same lock file, so an “existing lock” error is reported. The underlying issue is mixed-case refs; resolve it by consolidating the remote to a single-case variant and update local refs accordingly.
Quoted 5 lines
Are you aware of Karthik's recent patch series at [1]? It looks like this addresses your exact problem in a more direct way, and the resulting error messages that we have in that patch series also give a bit more advice for how to handle the situation.
Thanks for tagging me.
Quoted 4 lines
The patch series wasn't merged yet, but will probably be merged soon. Could you maybe test that series and say whether it addresses your need?
I agree. This should ideally be fixed with my series. Do let us know if you test it. My series also has the added advantage that it would suggest using reftables, wherein, the user can still use case-conflicting refs in their repository.
Quoted 5 lines
Thanks!
Patrick