-
Notifications
You must be signed in to change notification settings - Fork 147
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Managing file writes to tracked files (homeshick retrack) [Feature] [Discussion] #137
Comments
I have the same problem on OSX where BetterTouchTool does the same thing. Also: Instead of tracking the file, you could track the entire folder and create a .gitignore inside it:
That trick would actually be a nice addition to the wiki :-) |
Oh @andsens I hadn't thought of the entire folder with a gitignore. That's brilliant! |
@andsens I have a follow up. How do you tell homeshick to track a directory? So far I have the above you mentioned with the following tree:
and a
But when I perform a
Which is not what I want. I want Anyway thanks for the help and once I get that tip working I'm happy to add it to the wiki. |
Oh yeah, forgot about that part. Here: https://github.com/andsens/homeshick/wiki/Symlinking#shallow-symlinking
Oh, that'd be nice :-) |
Nice! Thank you @sukima. |
So I had a situation where I wanted to track a config file (
~/.tin/tinrc
to be exact) only to find out that the tin program on exit saves the config file. This is so that if you change your settings interactively through the program it is saved to the rc file. And like old unix-y programs to be save it does a write/move to prevent corruption during a system crash.What this means is it writes the contents to a temp file and then moves the temp file to the config file. Because Homeshick tracks changes by way of a symbolic link a write/move or a delete and write will blow out the symlink and construct a new file. Unfortunately the symlink is now broken and a track command will abort claiming it is already tracked.
There isn't any real way to manage this automatically even if it was a hard link so I propose a
homeshick retrack
command allowing the castle specified to scan it's contents (git ls-files) and attempt to first copy the contents over and then re-symlink them That way the tracking is replaced but the changes are not lost like the would with ahomeshick link --force
.Is there another idea for programs that end up buggering the symlinks as part of their execution?
The text was updated successfully, but these errors were encountered: