One thing which is not clear to me though: is the update happening only when the fetch command is explicitly called? Or the does plugin always force the local clone to get the latest updates from remote on every build?
The current versions of the Git and Git client plugin do not update the reference repository automatically. The reference repository must be updated manually. This is what the additional step "Periodically update the reference repository with the latest content from the original repository" is about.
I had used this functionality a few years ago - and it indeed made a huge improvement in space and performance - however, I ran into one issue that I'd be interested in knowing if has been resolved.
When I would update the reference repository - it seems like it would periodically result in broken/dangling references/links/etc. within the clones referencing it. It may have been in response to a gc or repack that was triggered in the reference copy.
It's been a while though since I used this. I'm looking to use it again though. Do you know if this is something that I was likely doing wrong with my update process previously, or should I be taking any special action in how the reference repository is used in the jobs?
Cloning using a reference works fine. However, the cloned repository is not standalone, the reference is still needed. As a result, when the cloned repository is used within a docker container where the reference is not available, git complains like:
error: Could not read 26fa13ae7fbe6eb887dfbdf182a6218d790203cd fatal: Failed to traverse parents of commit 82d549106c0b85d3e1e4444df018ba3f7cbb3d0a
Should the combined reference repository really be working with submodules added as remotes?
When cloning as suggested I get an error as follows:
submodule 'submodule1' cannot add alternate: path '.../reference-repository/.git/modules/submodule1/' does not existCloning into ...
Cloning searches in the reference repository under modules/submodule1/ where they are not provided in a bare repository. For a non-bare repository with inialized submodules this location would be correct.
Working solution: Cloning the main repository bare as suggested and providing all required submodules cloned under the modules/ folder (reproducing the expected structure).
Comments
6 comments
This is a great feature!
One thing which is not clear to me though: is the update happening only when the fetch command is explicitly called? Or the does plugin always force the local clone to get the latest updates from remote on every build?
Rafael,
The current versions of the Git and Git client plugin do not update the reference repository automatically. The reference repository must be updated manually. This is what the additional step "Periodically update the reference repository with the latest content from the original repository" is about.
Regards,
I had used this functionality a few years ago - and it indeed made a huge improvement in space and performance - however, I ran into one issue that I'd be interested in knowing if has been resolved.
When I would update the reference repository - it seems like it would periodically result in broken/dangling references/links/etc. within the clones referencing it. It may have been in response to a gc or repack that was triggered in the reference copy.
It's been a while though since I used this. I'm looking to use it again though. Do you know if this is something that I was likely doing wrong with my update process previously, or should I be taking any special action in how the reference repository is used in the jobs?
Hi,
Cloning using a reference works fine. However, the cloned repository is not standalone, the reference is still needed.
As a result, when the cloned repository is used within a docker container where the reference is not available, git complains like:
error: Could not read 26fa13ae7fbe6eb887dfbdf182a6218d790203cd
fatal: Failed to traverse parents of commit 82d549106c0b85d3e1e4444df018ba3f7cbb3d0a
From git manual, the 'dissociate' option should do it: https://git-scm.com/docs/git-clone#git-clone---dissociate
How to pass the 'dissociate' option to GitSCM?
thanks,
gautier
Should the combined reference repository really be working with submodules added as remotes?
When cloning as suggested I get an error as follows:
submodule 'submodule1' cannot add alternate: path '.../reference-repository/.git/modules/submodule1/' does not existCloning into ...
Cloning searches in the reference repository under modules/submodule1/ where they are not provided in a bare repository. For a non-bare repository with inialized submodules this location would be correct.
Working solution: Cloning the main repository bare as suggested and providing all required submodules cloned under the modules/ folder (reproducing the expected structure).
Is it possible to have a reference repo on the master that can be accessed by the agents? What would a sample path look like?
Please sign in to leave a comment.