How to have git repository in NFS partition and working-tree in local partition?

My home directory is in a remotely-mounted NFS partition on a file-server and is routinely backe开发者_如何学Cd-up. I would like to have my project's git repository be under my home directory (so that it's backed-up) but I would like my working-tree to be in a local disk partition of my workstation (so that building is fast). The local disk partition isn't backed-up.

Any ideas on how to do this? I know that I can clone the NFS repository and push to it, but that seems like unnecessary overkill.

Could it be as simple as creating a .git symbolic link in the local partition to the .git directory in the remote NFS partition?

You could create your Git repo with:

• the working tree being a current path on the local disk partition
• but the .git dir being specified with --git-dir=<path> or $GIT_DIR environment variable and referring to a path within your (backed-up) home directory.

The git init command takes into account the $GIT_DIR environment variable:

If the $GIT_DIR environment variable is set then it specifies a path to use instead of ./.git for the base of the repository.

Alternatively, you can create your repo in your home dir, but add the following git config:

core.worktree

Set the path to the root of the work tree.
This can be overridden by the GIT_WORK_TREE environment variable and the --work-tree command line option.
It can be an absolute path or a relative path to the .git directory, either specified by --git-dir or GIT_DIR, or automatically discovered.
If --git-dir or GIT_DIR are specified but none of --work-tree, GIT_WORK_TREE and core.worktree is specified, the current working directory is regarded as the root of the work tree.

Note that this variable is honored even when set in a configuration file in a ".git" subdirectory of a directory, and its value differs from the latter directory (e.g. "/path/to/.git/config" has core.worktree set to "/different/path"), which is most likely a misconfiguration.
Running git commands in "/path/to" directory will still use "/different/path" as the root of the work tree and can cause great confusion to the users.

The OP adds:

Could it be as simple as creating a .git symbolic link in the local partition to the .git directory in the remote NFS partition?

At least, with settings (like git-dir, or core.worktree), that allows to achieve the same effect without relying on the OS specific features like symbolic link (which is not available on every OS)

Update 2018 (8 years later): Tom Russell adds in the comments:

It appears that the --separate-git-dir flag is now used to point to .git/ on the NFS server when initializing the repository on the local workstation (NFS client).
Subsequent behavior is odd, though: Changes committed on the NFS client don't automatically propagate to the server, requiring a git checkout -- <file> on the server.

I subsequently figured out that a git reset --hard in the server repo after a commit in the client repo (or vice-versa) is the easiest way to bring a working directory up to date.

Create your repo in your home directory as usual, then on your fast local disk, use the script git-new-workdir (on my box, under /usr/share/doc/git-core/contrib/workdir). It's not a part of the git core; it's a contributed script but your distro's git package may have installed it. Usage is:

git-new-workdir <repository> <new_workdir>

This will create a new, distinct working directory that is linked to your original repository.

You can move your .git directory to a remote share, and then you can replace it with a file called '.git', containing 'gitdir: '. It is documented in repository layout help page (eg. git help repository-layout).

Not sure what you mean by overkill, but my suggestion would be to go ahead and have a clone in NFS and push to it.

You can set up a post-commit hook that does a git push --mirror my-nfs-thing and not have to even think about it.

Most importantly, you'll always have fast, reliable access to the repository data (without the fear of losing data to system failures, etc...).