Target can have two opposing meanings:
1. the target directory where symlinks are managed by Stow, and
2. the destinations of those symlinks
So try to move away from this by using the word "destination" for
symlinks.
This should have been part of 182acbbb64
when the option was first added.
This commit basically just copies the help text from stow.in into the
texinfo manual.
This avoids errors like
fatal: You are pushing to remote 'savannah', which is not the upstream of
your current branch 'master', without telling me what to push
to update which remote branch.
Under emacs, this was previously rendered as
'--no-folding'
This disables any further *note tree folding:: or *note tree
refolding::. If a new subdirectory is encountered whilst stowing a
which looks awkward. Similarly under info(1):
'--no-folding'
This disables any further *note tree folding:: or *note tree
refolding::. If a new subdirectory is encountered whilst stowing a
The new way is undesirably repetitive, but at least grammatically
correct. I don't think there's a better solution with texinfo :-/
It doesn't make sense to have docs online relating to a release which
isn't yet available; it's less confusing to have a small time window
in which the online docs are out of date.
Add a new expand_tilde() function that performs tilde expansion of
strings, and corresponding unit tests:
* A ~ at the beginning of a path is expanded to the user's home
directory.
* Literal '~' can be provided with '\~'
Combine this with expand_environment() in a new expand_filepath()
function which applies all (both) required expansion functions to a
string, and use that in get_config_file_options() to expand .stowrc
options.
Add more tests to check that tilde expanded in correct places, i.e.:
* expanded for --target and --dir
* not expanded for --ignore, --defer, or --override
Update documentation on stowrc files according to this functionality
change.
Fixes#14: https://github.com/aspiers/stow/issues/14
De-emphasise the package management aspects, since these days
almost everyone prefers to use modern package managers such as
rpm / dpkg / Nix for (system-wide) package management.
Also include more popular modern use cases for Stow such as management
of dotfiles and software compiled in the user's $HOME directory.
Fixes#22: https://github.com/aspiers/stow/issues/22
Charles LeDoux did some awesome work providing this Docker environment
which can test across multiple Perl versions using perlbrew, so it
would be crazy not to use it.
Let's try a new approach where we increment the version number
immediately after publishing a release, not just before.
This will mean that anyone who builds from git gets a version of Stow
which is higher than the release which was just cut, and this could
provide valuable debugging hints in case a bug report does not clearly
state whether the problem arose with the latest release or with a build
from git.
