Hi Paul, > How about something like the attached patch? The idea is to use hard links by > default (the longstanding practice)
No, something is not a good default if it requires editor customizations in order to work correctly. It is "longstanding practice", yes, but I did not perceive how badly it operates, because I was always putting my testdirs in /tmp, thus avoiding the hard links. I can add options -h / --hardlink, -H / --more-hardlinks, with similar logic as -s / --symlink, -S / --more-symlinks. But before doing that, I'd like to understand whether it's worth the added complexity. Namely, wouldn't symlinks work as well as hard links for you? vi, emacs, kate have the same backup behaviour for symlinks: leave the symlink in place and add the backup file in the directory of the target (i.e. in the gnulib checkout). I find this a better starting point for new users if all editors do things in the same way. > I prefer the hard links; for me, they work better than symlinks would, > because > Emacs would chatter at me about following symlinks. You mean the question Symbolic link to Git-controlled source file; follow link? (yes or no) When you set vc-follow-symlinks to nil, it does not ask any more, it only shows a warning Warning: symbolic link to Git-controlled source file Really I wonder about the point of these two warnings Warning: symbolic link to Git-controlled source file Warning: editing through the link bypasses version control found in emacs/lisp/vc/vc-hooks.el. If the target file is under version control, it gives the user the ability to review and undo unintended changes afterwards. Whereas if the target file is NOT under version control, changes can not be reviewed, and the edit history is limited. Therefore it's the opposite situation which should warrant a warning! Warning: editing a file that is not under version control Bruno
