On Wed, Aug 16, 2023 at 01:21:11AM +0000, brian m. carlson wrote: > On 2023-08-15 at 04:05:34, Grant Singleton wrote: > > Thank you for filling out a Git bug report! > > Please answer the following questions to help us understand your issue. > > > > What did you do before the bug happened? (Steps to reproduce your issue) > > > > With 3 clones of a repo, one on branch-a one a mirror, another using the mirror as a reference repo on branch-b, do the following > > > > # in the repo on branch-a, make a change, commit and push > > cd bad-object-test > > echo $(( RANDOM % 1000 + 1 )) > file.txt > > git ci -am "change a file" > > git push > > > > # do a git fetch in the reference repo > > cd ../bad-object-test.git/ > > git fetch > > > > # do a git pull in the repo on branch-b > > cd ../bad-object-test-with-reference-repo/ > > git pull > > > > # All good so far > > > > # in the repo on branch-a, discard HEAD and force push > > cd ../bad-object-test > > git reset --hard HEAD~1 > > git push --force > > > > # do a git fetch in the reference repo and then prune loose objects > > cd ../bad-object-test.git/ > > git fetch > > git prune -v --expire=now > > When you clone using --shared or --reference, you implicitly depend on > the objects in the referenced repository existing without being pruned > for the integrity of the repository. > > The manual page for git clone says this: > > NOTE: this is a possibly dangerous operation; do not use it unless you > understand what it does. If you clone your repository using this > option and then delete branches (or use any other Git command that > makes any existing commit unreferenced) in the source repository, some > objects may become unreferenced (or dangling). These objects may be > removed by normal Git operations (such as git commit) which > automatically call git maintenance run --auto. (See > git‐maintenance(1).) If these objects are removed and were referenced > by the cloned repository, then the cloned repository will become > corrupt. > > If you want to change the references in any non-fast-forward way or do > any sort of GC or pruning in the reference repository, you need to run > `git repack -a` in the non-reference repository to repack all of the > objects in that repository and dissociate it from the reference > repository. > > In general, unless you are _very_ sure you know what you're doing, you > usually want to use `--dissociate` with `--reference` such that you > detach immediately. > -- > brian m. carlson (he/him or they/them) > Toronto, Ontario, CA Ok, sorry and thanks, I should have read more of the documentation. For some context, we're doing this on a bunch of Jenkins agents for our CI/CD pipeline on a somewhat bloating monolithic repo. We have 30-40 clones on each machine, so the reference repos save us a lot of network traffic, time to fetch and disk space. So IIUC I can do a `git repack -kad` in the reference repo to pack loose objects and keep unreachable commits that may be referenced by other repos using the reference repo. Grant Singleton Christchurch, New Zealand
