[Q] Tell Git to follow symlinks?

Hi, list!

Sorry for a rather dumb question.

I'm trying to build a rudimentary GIT-based backup system for my remote host.

I want to put all relevant data (which is scattered throught the system) under single large Git backup-only (i.e. no development) repository.

And then on the remote system set cron to do something like

    git add . && git commit -m "`date`" && git gc

And on local system set cron to do git pull.

I thought to construct my repo of the number of symlinks to other places, but apparently Git does not follow any simlinks.

I have considered using zillion of git submodules, but looks like this solution would demand more work than I'd like to put in there.

Please give me some directions on the building such dumb backup system I want :)

Thanks in advance, Alexander.

"Alexander Gladysh" <agladysh@gmail.com> writes:

Hope so, I use this feature, for example to manage my debian alternatives.

I use "reverse" symlinks: the files i want to manage are replaced by symlink to the file that is in then git repository:

my home contain:

.abbrev_defs -> .myconfig/abbrev_defs .bash_logout -> .myconfig/bash_logout .bash_profile -> .myconfig/bash_profile .bashrc -> .myconfig/bashrc .custom -> .myconfig/custom .dircolors -> .myconfig/dircolors .emacs -> .myconfig/emacs .gnomerc -> .myconfig/gnomerc .gnus -> .myconfig/gnus .irssi -> .myconfig/irssi/ .profile -> .myconfig/profile .ScrollZ -> .myconfig/ScrollZ/ .scrollzrc -> .myconfig/scrollzrc .xchat2 -> .myconfig/xchat2/

and a .myconfig git repository that manage those file.

On Sun, Feb 24, 2008 at 6:08 PM, Remi Vanicat <vanicat@debian.org> wrote:

I do not advocate removal of this useful feature, but may be there are some arcane switch or even a simple source hack that would help me in my specific case, :)

Yes, this is an option, thank you. But it would involve altering existing software configurations (like enabling FollowSymLinks in Apache etc.) -- which I would like to avoid if possible.

Thank you, Alexander.

On Sun, Feb 24, 2008 at 3:08 PM, Remi Vanicat <vanicat@debian.org> wrote:

[...]

For configuration files I tend to actually physically copy them to a directory under the tree that I'm archiving using git, just because it feels slightly safer. If something git related goes wrong (probably due to my input) it can't, eg, stick an old, corrupted version of, eg, .bashrc in my home directory, which stops terminal login when I next reboot. (I had something similar happen when I actually had the live version of my archiving script being put into the archive. When I checked out a previous tree to look at something, an old buggy archiving script got checked out and created half a dozen corrupt commits I had to reset away.) Of course, the odds of anything like this happening in practice are quite small.

"Alexander Gladysh" <agladysh@gmail.com> writes:

Git stores symlinks as symlinks. Changing that (adding for example core.followSymlinks) would require quite a bit of surgery.

You can alternatively try to work with GIT_DIR, or/and with explicitely specifying worktree (and working from within repo), and/or symlinking .git.

Jakub Narebski <jnareb@gmail.com> writes:

In particular, this would raise the question of what to do when writting to a symlink. Following symlinks when doing a checkout or a merge could mean to allow git to write outside its working tree, which is problematic security-wise.