Thanks, that was fast! I'll give it a try soon (though perhaps not as quickly as
you did...).
> > for other
> > stuff that I'm working on, where the default value 'ask' is often the right
> > thing to do.
>
> Well, in this case, if for other projects 'ask' is better, I'll implement
> the options -h / --hardlink, -H / --more-hardlinks.
Implemented as follows:
2017-05-21 Bruno Haible
Hi Paul,
> > When you set vc-follow-symlinks to nil,
>
> I don't want to do that. I want to edit just one file and have it affect
> everything I'm working on
"gnulib-tool -S" and (setq vc-follow-symlinks nil) achieves just that, as far
as I can see from experiments.
> without hassling me about
Bruno Haible wrote:
I can add options -h / --hardlink, -H / --more-hardlinks, with similar logic as
-s / --symlink, -S / --more-symlinks.
I wasn't thinking of anything that complicated, though of course it would
suffice. I was just wanting the longstanding behavior.
You mean the question
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 badl
Bruno Haible wrote:
* When I edit a file in the testdir using 'vi', the change gets propagated
back to the gnulib checkout. But it does not do so with 'emacs' or 'kate'
as editor.
It works for me with Emacs, possibly because I have had the following in my
~/.emacs for many years:
gnulib-tool has done hard-linking for testdirs since the beginning, but it has
more drawbacks than advantages:
* When I am building a testdir and doing unrelated changes in my gnulib
checkout at the same time, especially on the .m4 files, it will trigger
a reconfiguration of the testdir,
