8

My home directory is in a remotely-mounted NFS partition on a file-server and is routinely backed-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?

Steve Emmerson
  • 7,702
  • 5
  • 33
  • 59
  • 3
    An alternative to making .git a symbolic link is to make a regular file named .git with contents: "gitdir: /p/a/t/h/.git". AFAIK, this is undocumented behavior and therefore subject to change. – William Pursell Feb 07 '10 at 06:30
  • Thanks for this question (and the answers), I always wanted to try this ... in my case the *local* partition would be the `/tmp/` directory, meaning it can get deleted at any time (between my sessions). So I would need a way to restore it from the repository easily. I'll try the suggestions. – Paŭlo Ebermann Feb 06 '11 at 13:19

4 Answers4

7

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.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • @Bombe: "wording improved" indeed, thank you ;) (improvement done in the true spirit of http://meta.stackexchange.com/questions/38242/full-time-dedicated-editors-on-so/38244#38244) – VonC Feb 06 '10 at 00:08
  • could the git-dir alternative you posted, be a solution to distribute multimedia (binary) content using git over to remote Android devices where I can't install Git? – microspino Aug 17 '10 at 08:58
  • @microspino: I don't have experience in this kind of environment, but this is certainly worth a try. – VonC Aug 17 '10 at 09:07
  • 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 -- ` on the server. – Tom Russell Jan 01 '18 at 03:54
  • @TomRussell Strange. I have included your comment in the answer for more visibility. – VonC Jan 01 '18 at 07:04
  • @VonC Nice. 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. – Tom Russell Jan 01 '18 at 20:37
  • @TomRussell OK makes sense. Maybe a push-to-deploy would avoid that: https://stackoverflow.com/a/30030236/6309 – VonC Jan 01 '18 at 20:39
4

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.

Wayne Conrad
  • 103,207
  • 26
  • 155
  • 191
  • Fantastic solution! – Tom Russell Jan 01 '18 at 05:54
  • 1
    A couple of caveats: After committing a change in the working directory, the other/remote directory can be brought up to date with a `git reset --hard`. Also, changes staged in one directory won't be reflected in the other. – Tom Russell Jan 01 '18 at 20:34
3

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

julian7
  • 311
  • 1
  • 5
0

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

Dustin
  • 89,080
  • 21
  • 111
  • 133