I’m pretty new to using git and was wondering if it’s ok to copy a Git repository with common UNIX commands (like cp or tar/untag), rather than through git clone.

I’m in the situation where I have a production environment (python virtual) that some code checked out in git in it. I’m wondering if it's a bad idea from a git perspective to copy down the whole environment using a tar or something. This approach would be convenient for making a quick copy of a codebase/environment.

My concern is that maybe git clone associates some unique id with the working copy that could cause conflicts if two working copies exist where one was filesystem-copied from the other.

  • Wow I was in this situation because I had some files under source control and some not, and I had file permissions I needed to preserve. I'm glad you asked this question. – Joe C Jun 2 '16 at 21:58

It is perfectly fine.

git stores all of its history, commits, etc. on site - this is a fundamental property of a DCVS.

Technically speaking, git can operate just fine with copied repositories running around everywhere, because the whole point of a DCVS is that it doesn't have to know what's going on outside of any given repository, and in fact doesn't unless you tell it.

The same principle applies here.

  • 1
    My understanding is that a cloned repository will contain a link back to the parent. Using an OS copy command will not create that link. – Tony Oct 5 '15 at 22:45
  • @Tony True, but you can remove that link by using git remote remove origin, which stops Git from using the parent repository as an upstream. – new123456 Oct 6 '15 at 2:56

You should be able to copy the entire working directory to anywhere else on your system and have it continue to function as normal when using Git, Hg, or SVN. I can't comment on other SCMs.


This is a more unusual use case, but...

I've seen the repo utility make symbolic links in the .git directory. In that case, when you're doing a copy, you'd want to make sure you dereference symbolic links. E.g.:

cp -r -L <source-repo-dir> <destination-repo-dir>

It is OK but if you are about to share your repo with someone else, please consider the following:

  • Your config file might have remotes the other person might not care.
  • Your logs folder will have references that you might not want to share. Git is great at letting you do the nasty stuff on your computer until you are comfortable with the final result, and then push it to the remote to (occasionally) share it. Some of that nasty history might be in your reflog, so it is better to not share it IMHO.
  • Your info/exclude file might be ignoring some files only you want to ignore.
  • You can also have hooks, branches, and a bunch of other stuff which is personal and you prefer to not share...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.