0

User-Story

Say I've cloned a project and pushed my work and I'm done with it for now. I expect I may need to go back to it, so I'd like to keep the clone locally to quickly switch back, but there is also a chance I am done for good, so I'd like to dump the files from disk.

Question

Is it possible to do this? To "archive" the local repo so I only keep the directory and .git dir and git understands this state when running commands like git status?

[EDIT:] The main reason for this question is so I can be lazy and not have to go find the repo URL to re-clone when I go back to work. This is really not a critical need but it could be pretty handy.

Rafe
  • 1,937
  • 22
  • 31

3 Answers3

1

Instead of an archive, I would use git bundle

That will create one file, with the full repository history in it: you can easily back it up somewhere.
And you can clone your repository back from that one file.

You can make a script which would:

  • create a bundle
  • and generate a second script able to:

That way, you have two files to backup:

  • the Git repository as a bundle
  • the (generated) script able to clone and restore the remote origin URL once cloned from the bundle
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Is this by any chance a bare repo in a tar file or similar? – Mad Physicist Oct 03 '19 at 05:07
  • @MadPhysicist Not exactly: it would not include everything that a tar repo would. – VonC Oct 03 '19 at 05:19
  • @MadPhysicist Typically, local hooks would not be included (https://stackoverflow.com/a/50866035/6309, https://stackoverflow.com/a/17529039/6309) – VonC Oct 03 '19 at 06:21
  • This is pretty cool (really great for working offline if needed) but not quite there. I could write a little batch script to bundle a repo and remove the dir, but when cloning back out the origin is lost (it is set to the bundle file). The main reason for my question is so I can be lazy and not have to go find the repo URL to reclone when I go back to work ;). Any ideas? None of this is really critical. Just neat to know. – Rafe Oct 04 '19 at 21:35
  • 1
    @Rafe You had selected the right answer. Once cloned back from the bundle, simply change the origin back to any remote URL you want: `git remote set-url origin https://new/url` – VonC Oct 04 '19 at 21:36
  • @Rafe I have edited the answer to address your edit about the origin URL. – VonC Oct 05 '19 at 03:49
  • The primary reason for the question is to avoid having to remember the origin URL and just go back to work. It seems like the feature doesn't exist. gzip is probably the best workaround. This is a great post but it didn't solve the core issue. – Rafe Oct 08 '19 at 17:52
  • 1
    @Rafe gzip is not recommended, as it takes too much files which are specific to the original machine/can include sensitive information. It is best to have a script able to read the remote URL (See [`git remote get-url origin`]. (https://stackoverflow.com/a/32991784/6309), and generate 1/ a bundle, 2/ a new script able to clone that bundle and to reset the remote origin within the cloned repo, reset it to the URL that the first script has read. That way, you " avoid having to remember the origin URL ", as requested. – VonC Oct 08 '19 at 18:22
  • @VonC: I added a note to the answer that is a nod to your comment. gzip (actually tar would be what I'd use) will not contain any more sensitive info than than the repo itself. Since my original question was not related to transferring data in any way (just keeping it in place), I'm not sure this is a concern...? – Rafe Oct 09 '19 at 19:21
  • @Rafe It would include possible sensitive (config) or dangerous (hooks) information, hence `git bundle`. – VonC Oct 09 '19 at 19:29
1

Here are some options:

  1. (Preferred) Delete the folder and clone again when needed. You will need to pull when you start work again anyway. There is no much benefit in storing a stale copy.
  2. Keep the folder the way it is.
  3. Zip the folder if you want to save space.
tymtam
  • 31,798
  • 8
  • 86
  • 126
  • If #1 was preferred I wouldn't have posted this question ;). #2 isn't a solution to the question at all. #3 has some merit but again is not supported by git. It is just a workaround. – Rafe Oct 04 '19 at 21:17
  • I hear you, but I'm saying it's unnecessary work and in the end you'll do a `git pull` anyway. – tymtam Oct 05 '19 at 05:51
0

tar/zip seems to be the best workaround:

  • Effectively removes the files from IDEs/search/grok. Disk wasn't really an issue but this is a lot smaller.
  • Does not lose the origin URL so after unzipping there is nothing needed to begin working again, aside from pulling any updates.

Here is a guide randomly yanked from the net.

This is just a simple workaround. If you are after something more like a backup, especially if the plan is to transfer the files, see @VonC's answer.

Rafe
  • 1,937
  • 22
  • 31