Add ability to copy instead of linking certain files from a castle.

[mrmachine]

I'd like to include some default dotfiles in a collaboratively managed castle, that will be used by new staff who join our company. E.g. .gitconfig and .gitignore_global. These will be updated by each person and then they will be tracked them in each person's individual castles (or not).

I can do it with a bootstrap script and put the files in a default or template folder, but I'd like homeshick to simplify the deployment process and remove the need for users to execute a bootstrap script.

Perhaps files or folders with a .copy or #copy suffix would be copied instead of being linked? Or perhaps a .copy file in the castle root with relative paths (one per line) indicating which files should be copied?

Or perhaps post-clone.sh and post-link.sh files in the castle root could be sourced after clone and link operations, if they exist?

This could be the most flexible option, and would allow to do things like link or copy files into different directories depending on the environment. E.g. $ZDOTDIR or $HOME.

Has anything like this been discussed already in the past?

[andsens]

I understand the scenario and can see how such a feature would be useful. I can with certainty say that copying files instead of linking them is not something homeshick will ever do - it simply lies too far outside its intended scope (the control-flow for later features would diverge massively, like #98, #71 and #28). Also, for feature completeness the track command would have to know about it as well.
However: Solving #77 would allow you to create git hooks which homeshick can symlink into its own castles, meaning you can track those hooks, allowing you to implement one of your suggested solutions.

I have also recently refactored homeshick to be more easily forkable (in the development branch) - instead of having to merge large files like fs.sh and git.sh there are now files for each command. So you could just fork homeshick and have it do your bidding while being able to merge with upstream without any major hassle.

Closing.

p.s.: If you do decide to create a fork, you can add it to the list of notable forks if you like - I'm sure others in the same situation would be grateful :-)