0

I have some git clones sitting around that I don't particularly need (my copy isn't canonical, not in active use, no unpushed local commits), but also don't want to completely remove.

I'd like to exclude them from my backups, but retain a stub that I can use to re-create the local clone later (assuming the remotes still exist) without losing its config, remotes, branches, upstream/tracking relations, and so on.

Is there any safe, scriptable, straightforward way to generate a stub (perhaps a script to rebuild it, or a partial copy of its .git directory?) from an arbitrary git repo which can be used to rehydrate it later?

abathur
  • 1,047
  • 7
  • 19
  • 1
    Do you have local, unpushed commits? Also, consider whether a Git repository is a significant portion of a backup; is it worth the effort to exclude them? – Schwern Mar 10 '21 at 18:36
  • 1
    You can follow [these instructions to make a repository shallow](https://stackoverflow.com/a/40452701/14660) which will safely reduce the space. – Schwern Mar 10 '21 at 18:48
  • As I said, "no unpushed local commits". I'll re-consider shallow. I tend to avoid using it outside of CI because I always end up mindlessly pulling the full history at some point, but it might work well enough here. – abathur Mar 10 '21 at 21:51

1 Answers1

1

tl;dr: It may make sense to delete all/most of your local files and leave it that way for backup purposes. Next time you need to use the repo, just checkout a state you want and you're right back to where you were before.

Details:

The best approach likely depends on the shape of your repository. By this I'm referring to the storage size of the repo history vs the storage size of a checked out branch. You can get an idea by looking at the size of the entire repo directory, and comparing it to the size of the .git directory on its own. In my experience the checked out branch is usually bigger than the entire size of the repo. For example, the repo I work in daily has a .git directory of about 3.5 GB, and when I check out master it adds an additional 7 GB (totaling 10.5 GB). If I build one of larger projects it adds an additional 15 GB. I tried a shallow clone before and it only shaved off 0.75 GB from the .git directory, despite a 15 year history and 40K+ commits.

Assuming your checked out branch is larger than the amount of space you would save from a shallow clone, I think in your case I would try checking out a new branch, perhaps call it "stub" or something obvious. Delete everything except your .git directory, and possibly leave any untracked files that have personal settings in them. Commit it (or don't) and leave it in that state. In theory you should be able to check out any other branch, and do the necessary builds to get right back where you were before.

Note you could also do a shallow clone if your history is such that it would make enough of a difference. You'll probably have to test it first in order to know for sure.

As for scripting this, that really depends on what untracked files you need to keep around. The git command to create a branch is straight forward. Of course only you will know how complex the delete portion of the script would need to be.

TTT
  • 22,611
  • 8
  • 63
  • 69
  • I like the thinking, though I don't particularly want to remove the files right now (just skip backing them up, and be able to readily recover them after a restore from backup). I'll play around a little with shallowing them and excluding all but the .git folders. – abathur Mar 10 '21 at 22:05