Git checkout branch and prune everything related to previous checkout (incl. git-lfs remains)

Question

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.

Problem

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

Questions

1. How to checkout an existing branch fetched from remote, delete the previous branch and clean up any remains?

2. 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.

Solution Prototype

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

Questions to Prototype

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)

Pandarus

One solution is VFSForGit ... You can transport it to this ... If you do not want it like this, warn and I keep investing – Bream

@NicolásAlarcónRapela I've been watching the VFSForGit and it is promising, but at this moment it's Azure DevOps only, not supported on GitHub yet. I'm also unclear if it is production ready – Pandarus

Currently I have about 320GB in a VFS project ... anyway use gvfs instead of git as commands ... In any case I would check if vfs supports its claims @Pandarus – Bream

@NicolásAlarcónRapela Good to know. I still have to wait for the VFS support on GitHub – Pandarus

@Pandarus GitHub announced they going to adopt gitvfs as early as November 2017 but I still don't see any references. Might be worth contacting their support and asking if they want any early adopters? – Religion

@Religion twitter.com/mloskot/status/1083493676112846849 :-) – Pandarus

Answer 1

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).

Pandarus

Answer 2

I don't know well about LFS, so pardon me if my answer does not match.

I think git worktree may be the solution as it allow you to have a single (local) repository for multiple working tree, and so, checkout multiple branches without duplicating the repository itself.

Radiomicrometer

Thanks for an interesting tip. Apart from being still considered a fairly experimental git worktree is not recommended in case there are submodules. I have quite a complex mixture of Git LFS and submodules. I'm not confident git worktree are production ready for such setup. – Pandarus

The current documentation for worktree recommends against using it for exactly this situation. Multiple checkout in general is still experimental, and the support for submodules is incomplete. It is NOT recommended to make multiple checkouts of a superproject.. – Religion