search

aspiers / stow

GNU Stow - mirror of savannah git repository occasionally with more bleeding-edge branches
http://www.gnu.org/s/stow/
GNU General Public License v3.0
589 stars 41 forks source link

~/.stow-global-ignore doesn't work #89

Closed eggbean closed 2 months ago

eggbean commented 2 years ago

This page mentions that it is possible to make a global ~/.stow-global-ignore, but it does not seem to work when I make one. I copied this from one of my (working) .stow-local-ignore files which I then deleted, but the ignores do not apply:

\.git
\.gitignore
.*\.(bak|tmp|notes)

The ~/.stow-global-ignore file is actually a stow symlink itself, but it's the same when making it into an actual file.

I'm using stow (GNU Stow) version 2.3.1.

eggbean commented 2 years ago

I still cannot figure out what is going on. There seems to be two issues:

...
  Using ignore file: ../../.dotfiles/.bin/scripts/.stow-local-ignore
    Using memoized regexps from ../../.dotfiles/.bin/scripts/.stow-local-ignore
    Ignore list regexp for paths:    /(?^:(^|/)(^/\.stow\-local\-ignore$)(/|$))/
    Ignore list regexp for segments: /(?^:^(src|.*\.env|dir_colors)$)/
  Not ignoring dynu.sh
Stowing ../../.dotfiles/.bin / scripts / dynu.sh
  => ../../.dotfiles/.bin/scripts/dynu.sh
  is_a_link(dynu.sh)
  link_task_action(dynu.sh): link task exists with action remove
  is_a_link(dynu.sh): returning 0 (remove action found)
  is_a_node(dynu.sh)
  link_task_action(dynu.sh): link task exists with action remove
  dir_task_action(dynu.sh): no task
LINK: dynu.sh => ../../.dotfiles/.bin/scripts/dynu.sh (reverts previous action)
eggbean commented 2 years ago

Can anybody else confirm that ~/.stow-global-ignore doesn't work? Does anybody know if it worked in any previous versions? I could consider downgrading to an earlier version if it doesn't have the issues of the current version and if that version doesn't lack any features that I use.

gutierri commented 1 year ago

I confirm the problem.

The .stow-local-ignore rules override the .stow-global-ignore rules. The ideal would be a mix of the two files.

version: from source (4ef5eca)

eggbean commented 1 year ago

Thanks for confirming this. I use this program heavily, so I'm really looking forward to someone fixing the little bugs present in the current version.

gutierri commented 1 year ago

I found out where the bug is. I need some time to figure it out. Thinking that the files join the two rules at the end ---- On Mon, 19 Sep 2022 01:17:10 -0300 @.*** wrote ---- Thanks for confirming this. I use this program heavily, so I'm really looking forward to someone fixing the little bugs present in the current version.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

eggbean commented 1 year ago

Me trying to be helpful:

https://metacpan.org/pod/File::Cmp

?

gutierri commented 1 year ago

The root of the problem is apparently here (line 1290). It returns the first rule it finds. the ideal would be to end the file checking loop while concatenating what exists.

What prevents this from being quickly fixed by me is time and experience with perl. I'm just a perl hobbyist. And I happen to use stow extensively as well. I hope to fix it soon or maybe some collaborator will help with this too.

https://github.com/aspiers/stow/blob/4ef5eca4a9d107b24e712bb4c2c91f47e7e0fb85/lib/Stow.pm.in#L1273-L1299

eggbean commented 1 year ago

Ask on StackOverflow?

gutierri commented 1 year ago

It's not about asking specific questions about perl, but understanding the behavior of the functions used by stow. This code snippet is responsible for validating the rules of the ignore files, but it needs to be understood and understood how the other dependent functions use it and adjusted to include more than 1 value when there is more than 1 file.

gutierri commented 3 months ago

@aspiers Could you classify this issue as a bug (add label bug)?

aspiers commented 3 months ago

@gutierri Do you mean this:

From looking at the verbose log, when there's a .stow-global-ignore, ~/.stow-global-ignore seems to be ignored.

I guess that was a typo and meant to say

when there's a .stow-local-ignore, ~/.stow-global-ignore seems to be ignored.

That's not a bug - it's working as designed and documented, because creating a local ignore file is the currently only way to disable patterns in the global one.

That said, I certainly agree that it would be useful to be able to combine both global and local. For that ideally we would have something similar to .gitignore rules, where you can use ! to negate a previous rule. (BTW coincidentally many years ago, I implemented the git check-ignore subcommand!)

aspiers commented 3 months ago

Can anybody else confirm that ~/.stow-global-ignore doesn't work?

I can confirm that it definitely does work :stuck_out_tongue_winking_eye: I've been relying on that for years myself. But as per my previous comment, it does get overridden by a .stow-local-ignore.

aspiers commented 3 months ago

When I have .*\.env in both files, it still does not get ignored.

This does sound like a bug if true, but if that's reproducible please file a separate issue for it.

gutierri commented 2 months ago

@gutierri Do you mean this:

From looking at the verbose log, when there's a .stow-global-ignore, ~/.stow-global-ignore seems to be ignored.

I guess that was a typo and meant to say

when there's a .stow-local-ignore, ~/.stow-global-ignore seems to be ignored.

That's not a bug - it's working as designed and documented, because creating a local ignore file is the currently only way to disable patterns in the global one.

That said, I certainly agree that it would be useful to be able to combine both global and local. For that ideally we would have something similar to .gitignore rules, where you can use ! to negate a previous rule. (BTW coincidentally many years ago, I implemented the git check-ignore subcommand!)

You are right. It was a typing error.

When I have .\*\.env in both files, it still does not get ignored.

This does sound like a bug if true, but if that's reproducible please file a separate issue for it.

From this issue(#89), the only thing that needs to be investigated is the .*\.env. But I don't know if it makes sense to keep this isue open for that about .*\.env. I will analyze this problem in the coming weeks, and come back with some results, if I can reproduce it, I will come back signaling to close this issue and open a new issue about .*\.env.

aspiers commented 2 months ago

Thanks, please do file a new issue if needed. I don't think it makes sense to keep this one open, because the global ignore definitely does work in general.