Is it OK to copy (not clone) a git repository using basic Unix commands?

22

1

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.

Joe J

Posted 2011-07-26T17:54:47.233

Reputation: 456

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 – 2016-06-02T21:58:31.163

Answers

21

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.

new123456

Posted 2011-07-26T17:54:47.233

Reputation: 3 707

1My 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 – 2015-10-05T22:45:30.640

@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 – 2015-10-06T02:56:59.923

2

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.

Darth Android

Posted 2011-07-26T17:54:47.233

Reputation: 35 133

0

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

whoan

Posted 2011-07-26T17:54:47.233

Reputation: 103

0

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>

Craig McQueen

Posted 2011-07-26T17:54:47.233

Reputation: 1 020