Re: gnulib-tool: don't use hard links

[Bruno Haible]

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