Unlink of file '.git/...' failed #3336
Comments
|
Could you try to figure out what process is holding an open handle to that |
|
This might take a while. I'd have to wait until the problem reproduces itself first 😀 In the mean time, is it really a problem if Git would simply ignore being unable to delete in-use |
That is an interesting idea. Obviously, disk space would be wasted more easily this way, and if there was a consistent bug in the future that always keeps a handle to the pack(s) open while trying to clean up no-longer-needed packs, we would easily miss that bug, and disk space usage would skyrocket with every But as a band-aid, guarded by an opt-in config setting, this could be very useful. Are you up to implementing it? I would try to find some time to provide you with enough pointers to get started. |
|
I was able te reproduce the issue while GitKraken was running. I suspect if GK isn't running, it might be VScode's internal Git client causing this problem in a similar way. I've send some stern feedback GK's way, since I have proof that that's what is keeping those files locked. I haven't been able to prove the same thing for VScode, so I shouldn't be sending feedback their way just yet. Be that as it may, I'm not actually sure where the fix should be. I'm pretty sure software like that doesn't invent totally custom Git clients, but instead are using ready-to-use packages (or even the commandline) under the bonnet. I do think it's somewhat common to use the CLI and a GUI side-by-side. As for implementing that option: I'm sorry, but I'm not that kind of programmer. I don't think I'd be able to do a very good job. I can help testing though. |
|
The process holding the files is ... git itself - namely, the other instance of git. The process tree (as seen in Process Explorer) is: The topmost one holds all those handles to the files failing to unlink; the bottommost one tries to unlink them.
|
|
I guess it is that diff --git a/builtin/pull.c b/builtin/pull.c
index 3e13f810843..5d51c84d305 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -998,6 +998,7 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
oidclr(&rebase_fork_point);
}
+ close_object_store(the_repository->objects);
if (run_fetch(repo, refspecs))
return 1;
@mikekaganski do you think you could try that? |
Yes, I can try to build, but I need help to get an exact command/sequence of actions that would trigger the GC during the pull command. |
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes git-for-windows#3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes git-for-windows#3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
I opened a PR, and then used the PR branch to kick off a build the Git artifacts (installer and portable Git, for x86_64): https://github.com/git-for-windows/git/actions/runs/1209162450. Once that run succeeds (knock on wood), it will have the installer and the portable Git as a build artifact for you to test. If you want to try other things, just fetch the PR branch, make your own modifications, push it to your fork on GitHub, then kick off your own |
Thank you! |
|
@mikekaganski hmm. I am not quite sure. You could try to create tons of loose objects, but that might not trigger any repack. Or you could potentially lower the threshold for an auto-gc (see here for details). |
|
@mikekaganski here is the artifact: https://github.com/git-for-windows/git/suites/3701256089/artifacts/90330039 Please note that the CI build suggests that there is a bug with respect to the commit graph; If you have enabled that feature, please do not use that build, otherwise I would be glad if you tested it. |
|
Thanks - but in the meantime I have built it myself, and am testing ATM, with the |
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes git-for-windows#3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
At last I can report the "comparative" results (if a single test may be deemed such :) ) I have built git with your change; pulling using that version luckily triggered GC immediately; and it passed flawlessly. So based on this limited testing, I would assume the change works as intended - thank you! Looking forward to see it implemented :) |
|
Yeah! |
|
Just a note from an outsider, who admittedly doesn't know much about the low-level implementation details. It looks like this is a long-lasting problem. Hopefully this change fixes the last piece of it ;) - but possibly it could be also changed using a different sharing mode when opening files on Windows - see https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea, and its |
|
Right, there have been discussions about this. I forgot the details but from my vague memory seem to recall that it was not possible to use those flags (was it the fact that you can delete the file but then not recreate it under the same name until you reboot? Something like that). BTW there is now a new snapshot which has the fix. Since its executables are code-signed just like official releases (which anti-malware likes a lot more than unsigned binaries), you might want to switch to that snapshot version for the time being. |
|
Thank you for the explanation! Yes, this makes perfect sense - I didn't think about re-creating; that is a known problem of the scenario.
Thank you so much! Already using it! :-) Have a nice day, and thanks again! |
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes git-for-windows#3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes git-for-windows#3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0 (gc/repack: release packs when needed, 2018-12-15). This fixes #3336. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
Is there any progress to update? I met this error on a company computer(Everything workes well on other computers).It took me 2 days to try to fix this but failed. git version 2.36.0-rcl/2.35.2/2.35.1/2.28.0 Microsoft Windows Professional [Version 10.0.19044.1288] I have to write the code on this company computer now and diff/merge them manually on other computer now. I confirm that there is no process occupancy problem with ProcessExplore. Can someone help?Thanks very much. |
|
@byblinkdagger your issue might be a very new bug, but with the same suggestions to use Sysinternals' HANDLE or Process Explorer to investigate further. |
Thanks for your reply.I will continue to check with your suggestions in my spare time.In fact, when I cloned the Git for Windows SDK,i met the same error. Fortunately, when I work alone(use a personal branch,and just use git commit/push command,), it seems normal.I suspect it may be related to the company's internal control and monitor software now(only on my computer,so sad :) ). |
|
What Process Explorer show : Everything seems ok?(Sorry，i lack knowledge of windows and git.) |
|
It is quite possible that some part of Git tries to delete the Unfortunately, these things are notoriously hard to diagnose. Do you have any simple way to reproduce the issue reliably? |
It only happens on my company computer(Ghost Windows version ).Everything is normal on my colleague's computer.Now i use VMware(create a vm) to deal with team work due to urgent project schedule. |
That smells like anti-malware running a bit out of control. |
Setup
That's the 64 bits version, obviously.
defaults?
to the issue you're seeing?
I also use GitKraken, and this issues happens a lot while that's running, but also while it isn't (and even hasn't been sine the latest reboot). I also have VScode open all the time, which has a built-in Git client, but I'm not using it.
Details
CMD
Minimal, Complete, and Verifiable example
this will help us understand the issue.
But really many other commands trigger an automatic
git gc, as you (authors) probably know ;)When
git gctriggers automatically, don't complain when files can't be unlinked. As a user, I shouldn't have to care about that. Either git should ignore such problem (if it's harmless), or recover from it transparently.This "unlink" question repeats itself seemingly endlessly whether I answer yes or no. It's also impossible to know what the "right" answer is. Should I try again - I don't know, should you? Either way, answering yes just repeats the question for the same file. Answering no advances it to the next file, but god knows how many there are.
URL to that repository to help us with testing?
It's a general problem. Happens with multiple repo's, but most notably with very large ones. I wonder if this can happen with the repo for Git itself...
However, it does only happen after doing "some work". I'm not sure exactly when
git gctriggers automatically, but it does. And I'm not sure when it decides unlinking a file cannot be done and bothers the user with it, but it will happen "at some point".The text was updated successfully, but these errors were encountered: