threads / discuss / 25311

integrity of linux copy of a git repo

Subject: integrity of linux copy of a git repo

## tl;dr

2 messages between Oct 1, 2010 and Oct 1, 2010.

replies: 1people: 2as markdown or json

Neal Kreitzinger· Oct 1, 2010, 19:47 UTC · lore

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· Oct 1, 2010, 20:01 UTC · re: Neal Kreitzinger · lore

Re: integrity of linux copy of a git repo

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.

Show 6 quoted lines
> 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

← back to recent threads