Fixes 'dot-' preprocessing fails for dot-directories (#33, Savannah#56727) #70
Conversation
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 variables is used to keep track of the current level in the source.
|
Hi, I have tested this locally and can confirm that is solves the issue. |
|
Thanks a lot for the testing, I'll definitely take that into account! |
|
@aspiers please, tell me if I you want me to squash the commits or change something. Thanks. |
aspiers
changed the title
aspiers
changed the title
|
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. |
|
How long this PR is going to stay unmerged here, just wondering |
|
bump 🙏 |
|
I moved to another project (dotdrop) because the lack of active maintenance for stow.. This issue has now been open for 2 years! |
|
@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. |
|
@aspiers Hi. Is the project still alive? Can you please merge this? |
|
Hi. I have some questions, not unlike others here and elsewhere:
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:
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. |
|
@aspiers -- is there another GNU maintainer that can take this off your plate? There appears to be hands willing to help here. |
|
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 (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:
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 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. |
Your users all know what we signed up for: Lines 596 to 598 in 4ef5eca 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. |
|
@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. |
|
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. |
Filed as #104. |
|
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. |
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.