Can't Hard Link The Gitconfig File

Can't Hard Link the gitconfig File

Try Eli Barzilay's solution in his comment at http://www.xxeo.com/archives/2010/02/16/dotfiles-in-git-finally-did-it.html:

So I’ve finally found a solution that takes the best of both: put the repo
in a subdirectory, and instead of symlinks, add a configuration option for
“core.worktree” to be your home directory. Now when you’re in your home
directory you’re not in a git repo (so the first problem is gone), and you
don’t need to deal with fragile symlinks as in the second case. You still
have the minor hassle of excluding paths that you don’t want versioned (eg,
the “*” in “.git/info/exclude” trick), but that’s not new.

Git and hard links

The 'tree' object, representing directories in Git, stores file name and (subset of) permissions. It doesn't store inode number (or other kind of file id). Therefore hard links cannot be represented in git, at least not without third party tools such as metastore or git-cache-meta (and I am not sure if it is possible even with those tools).

Git tries to not touch files that it doesn't need to update, but you have to take into account that git doesn't try to preserve hardlinks, so they can be broken by git.

---

About symbolic links pointing outside repository: git has no problems with them and should preserve contents of symbolic links... but utility of such links is dubious to me, as whether those symlinks would be broken or not depends on the filesystem layout outside git repository, and not under control of git.

Bad git config file .git/config

For those hitting into this issue (I believe it's due to crashing out git mid init?) in windows, if you have a recent backup of the config file from your git repo's .git/ folder you can fix it by replacing the existing with it (any ref's added since the copy will obviously need re-adding) - not at all ideal but better than loosing all the commits.

Git symbolic links in Windows

You can find the symlinks by looking for files that have a mode of 120000, possibly with this command:

git ls-files -s | awk '/120000/{print $4}'

Once you replace the links, I would recommend marking them as unchanged with git update-index --assume-unchanged, rather than listing them in .git/info/exclude.

How can I get Git to follow symlinks?

NOTE: This advice is now out-dated as per comment since Git 1.6.1. Git used to behave this way, and no longer does.

---

Git by default attempts to store symlinks instead of following them (for compactness, and it's generally what people want).

However, I accidentally managed to get it to add files beyond the symlink when the symlink is a directory.

I.e.:

  /foo/
  /foo/baz
  /bar/foo --> /foo
  /bar/foo/baz

by doing

 git add /bar/foo/baz

it appeared to work when I tried it. That behavior was however unwanted by me at the time, so I can't give you information beyond that.

Can't make hard link for mounted host file in LXD container

This is not a container issue.
You cannot create hard links across mount points, even when it’s the same device you (bind) mounted to different places in your FS hierarchy.

Try this on your system:

> cd /tmp/
> mkdir bar
> mkdir barm1
> mkdir barm2
> sudo mount --bind bar barm1 
> sudo mount --bind bar barm2
> cd barm1
> echo foo > foo
> ll ../barm2/ 

drwxr-xr-x   2 user users   4096 Jul 13 15:56 ./
drwxrwxrwt. 19 root root  147456 Jul 13 15:57 ../
-rw-r--r--   1 user users      4 Jul 13 15:56 foo

> cp --link foo ../barm2/foo2

cp: cannot create hard link '../barm2/foo2' to 'foo': Invalid cross-device link

Unlink of file Failed. Should I try again?

This could mean that another program is using the file, which is preventing git from "moving" the file into or out of the working directory when you are attempting to change branches.

I have had this happen on Windows Vista where eclipse is the program "using" the file. The file may not be actually open in eclipse but may have been opened by a process run by eclipse.

In this event, try closing the file in any applications that might have used it. If that doesn't work, completely exit any applications which may have opened the file.

How does Git handle symbolic links?

From linux symlink manual (assuming you are in Linux):

A symbolic link is a special type of file whose contents are a string that is the pathname of another file, the file to which the link refers. (The contents of a symbolic link can be read using readlink(2).)

So a symbolic link is one more file, just as a README.md or a Makefile. Git just stores the contents of the link (i.e. the aforementioned path of the file system object that it links to) in a 'blob' just like it would for any other file. It then stores the name, mode and type (including the fact that it is a symlink) in the tree object that represents its containing directory.

When you checkout a tree containing the link, it restores the object as a symlink regardless of whether the target file system object exists or not.

If you delete the file that the symlink references it doesn't affect the Git-controlled symlink in any way. You will have a dangling reference. It is up to the user to either remove or change the link to point to something valid if needed.

Changing .gitconfig location on Windows

If you set HOME to c:\my_configuration_files\, then git will locate .gitconfig there. Editing environment variables is described here. You need to set the HOME variable, then re-open any cmd.exe window. Use the "set" command to verify that HOME indeed points to the right value.

Changing HOME will, of course, also affect other applications. However, from reading git's source code, that appears to be the only way to change the location of these files without the need to adjust the command line. You should also consider Stefan's response: you can set the GIT_CONFIG variable. However, to give it the effect you desire, you need to pass the --global flag to all git invocations (plus any local .git/config files are ignored).

---

Related Topics