Improve submodule performance when --use-submodules is not used #2795
Conversation
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
CosynPa
force-pushed
the
submodule-performance-no-use-submodule
branch
from
3670c0f
to
1fc4003
Compare
|
To make I also added a |
|
Do I understand correctly that you want to check if there is already a clone containing the branch & commit of the repository in Carthage's cache? If so then skip the cloning from remote? |
|
Yes, and even if the commit does not exist in the cache repository, we only need to fetch in the cache repository, no need to clone the whole every time. |
CosynPa
force-pushed
the
submodule-performance-no-use-submodule
branch
from
1fc4003
to
8aebf21
Compare
|
I removed the last commit which tried to solve the race condition problem because I found that commit did not solve the problem completely. The complete solution would be a little complex, so I think it's better to put it in another pull request. |
|
@CosynPa please update the branch from master to fix the CI |
…ation for the recursive submodule cloning.
CosynPa
force-pushed
the
submodule-performance-no-use-submodule
branch
from
8aebf21
to
366a573
Compare
|
Rebased onto master, but a test failed. Any idea? |
|
Yes, it's a test trying to get the remote version. It's unrelated to you PR so for me this is good. |
|
Thanks! 🎉 |
PRs «Fix fetching race condition (#2832)» and «Improve submodule performance when --use-submodules is not used (#2795)» provide benefits, but also major risk of cache clashes in the vein of <github.com//issues/569>. Basically, submodules before those two PRs had their bare git repos cached in way dissimilar to `~/Library/Caches/org.carthage.CarthageKit/dependencies` — that is they’re either “cached” how a git submodule init/fetch stores them or re-clone from remote with the subsequent checkout following a removal of the worktree. This regression slipped past our unit (and small number of integration) tests. And, upon further testing out of popular frameworks in combination, caused major issues. Follow up revert of associated commit <68abf2d73791720457f5be1aab4b57df86483f88> incoming. This reverts commit 55e416a.
…ed (#2795)" PRs «Fix fetching race condition (#2832)» and «Improve submodule performance when --use-submodules is not used (#2795)» provide benefits, but also major risk of cache clashes in the vein of <github.com//issues/569>. Basically, submodules before those two PRs had their bare git repos cached in way dissimilar to `~/Library/Caches/org.carthage.CarthageKit/dependencies` — that is they’re either “cached” how a git submodule init/fetch stores them or re-clone from remote with the subsequent checkout following a removal of the worktree. This regression slipped past our unit (and small number of integration) tests. And, upon further testing out of popular frameworks in combination, caused major issues. This reverts commit 68abf2d.
By using the repository cache instead of directly cloning the submodules from remote.