tracking relative symlink should change the symlink accordingly

[andsens]

When tracking a relative symlink, it gets moved into the castle where the reference is no longer valid. homeshick track should change that symlink so that it still points at the same location in the filesystem.

[mrmachine]

And it should remain a relative link inside the castle?

[andsens]

Yeah, I'd say so. You could add an -L switch so homeshick follows symlinks, but that can be saved for a later date, wouldn't you say?

[mrmachine]

So with -L, if I have ~/.zprezto as a symlink to Projects/prezto (a relative symlink), Homeshick would move ~/Projects/prezto (the actual folder) into the castle and replace it with a symlink, leaving the original ~/zprezto symlink intact?

And without -L, Homeshick would leave ~/Projects/prezto where it is, create a new relative symlink in the castle to ../../../../Projects/prezto and replace the symlink at ~/.zprezto so that it points to the symlink in the castle?

If so, I don't know if -L is that useful. You can achieve the same thing right now by just tracking the target of the symlink. But for the first case, when you are trying to track a symlink (relative or not), Homeshick should probably always try to convert the target of the symlink to a relative symlink from its new location inside the castle?

An absolute symlink inside a castle is not portable, and a relative symlink that is copied as-is from somewhere on the file system into a castle is never going to work at all.

[andsens]

Yes, to all of it :-) I agree completely. I don't really see the need for -L either. The way you describe the linking procedure is actually what I have in mind.

[andsens]

Fixed! :-)
Or at least I think it is... This is one those where it's quite hard to find all the edge cases. It might need to stay in the testing branch for a while before I am comfortable merging this into master.