Fixes 'dot-' preprocessing fails for dot-directories (#33, Savannah#56727)

[AitorATuin]

Fixes http://savannah.gnu.org/bugs/?56727 and #33.

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, each time it's called from stow_node ../ it's prefixed to the source. The solution there is just to keep track of the level of recursion and delete as many dots as levels.

In the case of unstow_contents the solution is just to provide the source from unstow_node.

[coveralls]

Coverage remained the same at 86.312% when pulling a41118d on AitorATuin:bug-56727 into 9fd3624 on aspiers:master.

[nabaco]

Hi, I have tested this locally and can confirm that is solves the issue.
Fixes #33

[aspiers]

Thanks a lot for the testing, I'll definitely take that into account!

[AitorATuin]

@aspiers please, tell me if I you want me to squash the commits or change something. Thanks.

[aspiers]

Thanks @AitorATuin, no further action necessary from your side - this is in my queue and will get to it as soon as I can. Scheduled for 2.3.3 due to the high levels of interest in this and #33.

[mortezadadgar]

How long this PR is going to stay unmerged here, just wondering

[d1egoaz]

bump 🙏

[rjekker]

I moved to another project (dotdrop) because the lack of active maintenance for stow.. This issue has now been open for 2 years!

[matteo-gambarutti]

@aspiers I was wondering if this project is still alive. I think it's a fantastic tool but it seems neglected for a while now.

[alator21]

@aspiers Hi. Is the project still alive? Can you please merge this?

[ghost-in-the-zsh]

Hi. I have some questions, not unlike others here and elsewhere:

1. Will this ever get merged? If so, when?
2. Will version 2.3.3 including this fix ever be released? If so, when?
3. Otherwise, @aspiers : can you make an announcement explicitly stating this project is officially unmaintained?

I'm not sure ignoring an official GNU project you're the official maintainer for is the best thing to do, especially after several prior statements about how you're still committed to the project's progress and giving people hope that a new release with the fix will come "soon"(tm).

If you're no longer interested in this project, can you, please, at a minimum, give this project some closure by doing the following within the next 2-3 days or so:

1. merge a fix (there're 2 different PRs with a fix to this issue);
2. release 2.3.3 with a fix;
3. explicitly state that 2.3.3 will be your final official release;
4. explicitly announce you will no longer be maintaining this project.

This way, the community is officially and explicitly aware of the facts, won't waste time expecting something that will never materialize after said release, won't keep bugging you about it, and can either migrate to using a different tool or, perhaps even, fork the project and a have new official maintainer that's committed to the project's progress (whoever that person chooses to be).

Thanks in advance.

[jbwhit]

@aspiers -- is there another GNU maintainer that can take this off your plate? There appears to be hands willing to help here.

[aspiers]

I've been working hard on the next release recently, including 4 solid days over the Easter weekend. Given my woeful absence from the project, I can totally understand this might sound like vaporware and yet more broken promises, so I've pushed the work in progress to the dev branch, so you can see all 117 new commits here: https://github.com/aspiers/stow/compare/dev

(Please note that GitHub orders that view from oldest to newest, so you'll have to scroll down and click the button to load more to see the latest. This is effectively a sneak preview of almost everything coming in the next release, which is right around the corner, although I still have a few more commits in progress.)

These 117 commits include a merge of this PR (with some alterations), and also properly eliminate the super annoying warning described in #65.

So to answer @ghost-in-the-zsh's very fair questions:

1. Yes, this PR will get merged. It's merged into the above dev branch. However there were still some remaining issues with the fix, and over the last few weeks I came up with an improved approach which is almost ready to go.

2. Yes, the next release will definitely include this fix, and I think there's an excellent chance I can get it done this weekend. I really thought (and fervently hoped) that the long weekend just gone would have been enough time to wrap this up and get a new release out. However whilst working on all of this, and coming back to Stow after a long time with a very rusty understanding of how all the nuances work, I realised that there was a lot of complexity in the code that was really hard to grok due to poor naming of variables / functions, missing comments, and confusing terminology, and it was really slowing me down. For example, here's a commit message I wrote about 30 mins ago:

testutil: rename parameter names to be less confusing

$target was the source of the link, and $source was the target
(destination) of the link. Obviously this was hopelessly confusing,
so rename to avoid this.

It doesn't take a rocket scientist to understand how this level of confusing naming schemes littered throughout the code could make it much harder to work with. Some of the good news is that a ton of that is already fixed in these 117 (and counting) new commits, I've blown away most of the cobwebs in my memory of how everything works, and now have a full understanding of how --dotfiles works. (I didn't write that code originally, I just merged it based on a partial understanding and on trust since it looked like a great contribution). This has not only made it easier for me to fix issues, it will make it easier for others.

However, even with all this new momentum, it's clearly time to get a new maintainer on board to ensure the project remains on a healthy footing. Even though I use Stow on a daily basis to manage my dotfiles, and therefore have a long-term vested interest in the project, it's obviously completely unacceptable to vanish as a maintainer for so long. Until 2020, I had a decent amount of free time for things like Stow. Then for various reasons (including co-founding a startup), I got exhaustingly busy. This is not an attempt at an excuse, or at dodging an apology. I am truly sorry for neglecting a project I love for so long, and I will write a full apology on the mailing lists along with the release announcement. I only mention this to provide an explanation, and to clarify that I absolutely have not lost interest in Stow.

But not having enough time to be the sole maintainer has harmed the project, and also caused me a great deal of guilt and anxiety. So I would like to find a strong co-maintainer who is able to review PRs, make releases when I'm unable to, perhaps help fix bugs, and is a good communicator and collaborator so that we don't end up stepping on each other's toes. Offers are welcome. BTW I have put quite a bit of effort over the years into documenting the release process, to raise the project's bus factor above 1.

However, this is not the right issue to be tracking that; we should start a new GitHub issue for expanding the maintainership team. And indeed, this is not the right issue for most of this message, but it's one which seems to have a lot of eyeballs, and I felt it was more important to break the silence and provide answers than to let my perfectionist tendencies cause further procrastination. I'll do more proper communications this weekend in the right places. My first priority is getting this release out of the door. Then I can start to clean up some of the other mess, make plans for the longer term.

[StephenWithPH]

I am truly sorry for neglecting a project I love for so long, and I will write a full apology on the mailing lists along with the release announcement.

But not having enough time to be the sole maintainer has harmed the project, and also caused me a great deal of guilt and anxiety.

Your users all know what we signed up for:

stow/COPYING

Lines 596 to 598 in 4ef5eca

	PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
	IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
	ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

You contributed a useful thing to the world. Full stop.

To the extent that the project is now causing you grief, I apologize on behalf of your users. Thank you for the work you've done.

[nullman]

@aspiers It's really cool to know that you are still working on this project. I've been using stow for years and didn't want to change to one of the other options unless absolutely necessary. I look forward to your update. Your work is very appreciated.

[aspiers]

Thank you very much for the kind words. It's not the project which was causing me grief, it was my poor prioritization and communication. I've definitely learned lessons here, and I'll do my best to avoid history repeating.

[aspiers]

we should start a new GitHub issue for expanding the maintainership team.

Filed as #104.

[aspiers]

v2.4.0 is released with this fix! See https://ftp.gnu.org/gnu/stow/

I'm just updating the website and preparing an announcement email.