I have a repo of a superproject with number of submodules. lots of files of both are in Git LFS.
The repo comes with multiple long-lived release branches.
The complete clone transfers 20 GB of Git and Git LFS objects.
Checkout of master deflates the total repo to 40 GB in total, that is the objects and the working tree files together.
Let's consider three separate clones as canonical way to create three working copies, one per the long-lived branch:
git clone --branch master --recursive --jobs 8 https://repo repo_master
git clone --branch release/1.0 --recursive --jobs 8 https://repo repo_release1
git clone --branch release/2.0 --recursive --jobs 8 https://repo repo_release2
I'm trying to work out a network-optimised equivalent of the above: - clone once with the default master checked out - make multiple copies of the cloned repo - checkout release branches
How to checkout an existing branch fetched from remote, delete the previous branch and clean up any remains?
How to clean up everything related to the previously checked out master and its working tree, any cached previous LFS downloads etc.?
But, to keep the history of origin/master.
Here is what I have come up with for the the network-optimised workflow:
git clone --branch master --recursive --jobs 8 https://repo repo_master
cp -a repo_master repo_release1
cp -a repo_master repo_release2
cd repo_release1
git checkout -b release/1.0 --track origin/release/1.0
git pull
git submodule update --init --recursive --jobs 8
git branch -D master
git lfs prune
git submodule foreach --recursive git lfs prune
git lfs checkout
git submodule foreach --recursive git lfs checkout
Does it look correct or any steps are missing/redundant?
Does it make sense to run any of these, at which point?
git gc --aggressive --prune=now
git submodule foreach --recursive git gc --aggressive --prune=now
Please, assume, no new commits will happen locally between the
git clone --branch master ...
and cp -a repo_master ...
.
(The problem was also posted to Git mailing list and Git LFS at GitHub)
DESCRIPTION. Deletes local copies of LFS files which are old, thus freeing up disk space. Prune operates by enumerating all the locally stored objects, and then deleting any which are not referenced by at least ONE of the following: ○ the current checkout.
Checkout scans the current ref for all LFS objects that would be required, then where a file is either missing in the working copy, or contains placeholder pointer content with the same SHA, the real file content is written, provided we have it in the local store. Modified files are never overwritten.
git fetch --prune is the best utility for cleaning outdated branches. It will connect to a shared remote repository remote and fetch all remote branch refs. It will then delete remote refs that are no longer in use on the remote repository.
remove the file from your project's current file-tree. remove the file from repository history — rewriting Git history, deleting the file from all commits containing it. remove all reflog history that refers to the old commit history. repack the repository, garbage-collecting the now-unused data using git gc.
So far, no satisfying answer to the question arrived on the Git mailing list (linked in the question) or here. The only answer received was given by Brian from Git LFS project on GitHub. I'm copying it below.
I think this approach seems fine. I don't think it's necessary to run a
git gc
here, and it likely wouldn't have an effect due to the reflog anyway.
My thanks to Brian for the confirming my workflow.
Disclaimer: I suggested Brian to post the answer here, but he doesn't seem to use SO. I don't feel accepting my own forward of Brian's answer is the right thing to do, so I'm leaving this as an unaccepted answer (hopefully SO moderators will agree).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With