Are git repositories portable between operating systems and file systems

Question

... particularly when moved through FAT32 or exFAT USB flash drives?

Even though the working copy is probably going to suffer permissions changes, and obvious removal of symbolic links (if using them)... which are changes that Git is going to detect nicely, apart from that, are the .git/ directory contents sound enough as to allow moving a repository from one operating system and/or file system to another? e.g. Windows, common Linux distributions, macOS, NTFS, ext FS, APFS...

I can assume Git version 2+ if necessary.

Answer 1

Yes, the repository database is usually portable across all modern operating systems, including Windows. It doesn't rely on any extended attributes, and so far doesn't rely on case-sensitivity either. Filenames inside the database seem to be 52 characters max.

The main requirement is that filenames preserve their case, even on case-insensitive filesystema (e.g. if you copy .git/HEAD from ext4 to FAT32 to APFS to HFS+ to ext4, it should remain .git/HEAD and not become .git/head). Fortunately all filesystems listed above are case-preserving so that's fine.

One thing to keep in mind is that each branch or tag is represented as a separate file under .git/refs. Git imposes a strict character-set limit in order to work with any filesystem, but that isn't always enough – if you are moving to a case-insensitive filesystem (such as APFS or NTFS) better hope that the repository doesn't contain multiple branches or tags differing only in case. Likewise, Git doesn't forbid the use of legacy DOS device names such as aux or nul as branch/tag names.

---

(Technically, moving the repo across different filesystems might lose some file metadata such as the "read-only" (a-w) state of object blobs, but this is not something that Git itself looks at anyway.)

---

If you use FAT32 only as a temporary transport, consider using git pack-refs --all --prune and rm -rf .git/logs to avoid any branch-name issues, as unlikely as they are. Also run a git repack -d; git prune to reduce the number of loose object files.

You can even use git bundle to create a transport-friendly blob containing all or part of commit history.

Answer 2

While copying the .git directory will work in most cases, there are some caveats that need attention:

• git-svn may remember some user information that you don't want to copy, such as name and email address, for example in .git/logs/refs/remotes/trunk.

• A cloned repository will contain a link back to the parent which the copy command will not uncreate. You can remove that link by using git remote remove origin.

• If you have symbolic links in the .git directory, you'd want to make sure you de-reference them. For example:

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

• Some configuration items may vary across platforms, like custom diff drivers and hook scripts which reference external programs. When copying between different platforms one should verify items like core.ignorecase, core.autocrlf, core.safecrlf, core.fileMode and probably some others.

• git clone is a safe operation that can operate between computers:

  git clone ssh://[email protected]/path/to/my-project.git
  

  Cloning automatically creates a remote connection called "origin" pointing back to the original repository, making it easy to interact with a central repository.

You might find interesting reading the following tutorial for selectively moving a git directory:

How to move a full Git repository