# integrity of linux copy of a git repo

2 messages from 2010-10-01 to 2010-10-01. Participants: Neal Kreitzinger, Jonathan Nieder.
Thread: https://gitlist.dev/t/25311

## Neal Kreitzinger, 2010-10-01 19:47

Subject: integrity of linux copy of a git repo
Message-ID: <i85dub$fp5$1@dough.gmane.org>
URL: https://gitlist.dev/e/i85dub%24fp5%241%40dough.gmane.org

```
If I make a recursive linux copy, "cp -rfp", of a git repo working tree is 
the resulting copy interchangeable with the original?

e.g.
/orig-wk-tree was created via git-clone with the file:/// url and therefore 
is a "full copy"
cp -rfp /orig-wk-tree /orig-wk-tree-copy
(do some stuff that breaks /orig-wk-tree)
rm -rf /orig-wk-tree
mv /orig-wk-tree-copy /orig-wk-tree

Have I truly recovered the full integrity of the original, or have I 
unwittingly introduced some sort of corruption?

v/r,
Neal

```

## Jonathan Nieder, 2010-10-01 20:01

Subject: Re: integrity of linux copy of a git repo
Message-ID: <20101001200102.GA1882@burratino>
URL: https://gitlist.dev/e/20101001200102.GA1882%40burratino
In-Reply-To: <i85dub$fp5$1@dough.gmane.org>

```
Hi Neal,

Neal Kreitzinger wrote:

> If I make a recursive linux copy, "cp -rfp", of a git repo working tree is 
> the resulting copy interchangeable with the original?

Yes, the git metadata does not hardcode the path to the repo anywhere.
See gitrepository-layout(7) for perhaps more detail than you wanted.

You might want to use "git add --refresh ." (or even just "git diff")
to update the cached stat() information before starting work with the
new worktree, but that only matters if you are going to use very
low-level commands.

> cp -rfp /orig-wk-tree /orig-wk-tree-copy
> (do some stuff that breaks /orig-wk-tree)
> rm -rf /orig-wk-tree
> mv /orig-wk-tree-copy /orig-wk-tree
> 
> Have I truly recovered the full integrity of the original

Sure, that's a good way to do experiments.

Hope that helps,
Jonathan

```