Problem was that when running stow_contents/unstow_contents recursively from
stow_node/unstow_node the information for the source path (without the dot- to
. transformation) was lost.
In the case of stow_contents the solution is just to remove the leading
dots (..) from the $source path (since the $source path is passed as an argument
to the function)
In the case of unstow_contents the solution is the same as for stow_contents but
the arguments was now passed so I added it to the function.
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.
t/cli.t calls scripts which run with the first perl found in the
user's PATH (usually the system perl), not with the perl used for the
build, as reported here:
https://rt.cpan.org/Ticket/Display.html?id=129944
Thanks to Slaven Rezic for spotting this and reporting it!
stow 2.3.0 added external runtime dependencies on Hash::Merge and
Clone::Choose. Historically stow hasn't had runtime dependencies other
than Perl itself, which is a useful property if you're managing the
installation of Perl using stow; the bootstrapping instructions in
stow's manual would need updating to describe how to install these two
modules (and any dependencies they have now or in the future) as well.
However, Hash::Merge is much more general than stow actually needs, so
replace the merge() call with a few lines of equivalent code -- this
avoids the external dependencies, and is clearer than the merge()
call.
Many thanks to Adam Sampson for this patch:
https://lists.gnu.org/archive/html/bug-stow/2019-06/msg00001.html
.stowrc can be obtained from $HOME and/or the current working
directory; however only the $HOME case was tested before, because
during tests Stow was being run from $HOME.
So switch $TEST_DIR to an absolute path, create a new run_from/
subdirectory, and chdir to that before invoking any Stow code. This
allows us to test the behaviour of .stowrc in $HOME and run_from/
separately.
