Getting git to follow symlinks (again)

Somebody already asked how you can get git to follow symlinks. There was an answer for a symlinked directory, but not for a symlinked file. It was also over a year ago.

Question: how do you get git to follow a symlink and add the file it refers to?

  • “Unable to determine upstream SVN information from working tree history”
  • Bitbucket: Update a fork to merge changes of master repo?
  • how to create a file with the cmd?
  • why git-svn should search aggressively for old history?
  • Install git via homebrew on mac osx 10.10 results in: Error: Permission denied - /usr/local/lib/perl5/site_perl/5.18.2
  • Changing git conflict markers
  • Here is the old question: How can I get git to follow symlinks?. There’s also a question about what git typically does How does git handle symbolic links?. I’m after a way of changing this behaviour.

    In case you care: I’m running git 1.5.4.3 on unix and git version 1.6.0 on mac.

  • xcode remove repository from project
  • Upstream pulls with the GitHub desktop client
  • git update-index --assume-unchanged and git reset
  • How can I limit the log to all the descendants of a given commit?
  • Download a single folder or directory from a GitHub repo
  • Forgot “git rebase --continue” and did “git commit”. How to fix?
  • 4 Solutions collect form web for “Getting git to follow symlinks (again)”

    I’m pretty sure there’s no way.

    Additionally, it sounds like a kind of insecure, undefined behavior – what should it do when you move between versions of the file and it needs to write to it? In particular, if you check out a revision before it was added, do you really want it to remove the contents of a file outside the repository? What happens if you come back to present and recreate the file, or if the symlink itself is modified – should git also track the symlink itself?

    Things along these lines were said on the git mailing list late last year in response to essentially the same question.

    You can use hardlinks instead of softlinks (a.k.a. symlinks). Git will then see the contents of the linked file. The disadvantage is that when someone checks out, the file is created as a normal file in the checked-out directory, because Git does not understand it as a link.

    how about using hard links, then git has no idea its a linked file (does it?)

    The trouble with using hardlinks is that if something writing to the other location replaces the file, rather than just writing changes to it, then the destination file has a new inode on the filesystem and the hardlink no longer points to it, so the files are out of sync.

    Git Baby is a git and github fan, let's start git clone.