-
Notifications
You must be signed in to change notification settings - Fork 179
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add "not" support for alternates #365
Labels
Comments
This issue has been labeled as stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
This issue has been labeled as stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
This is now available in develop, with the syntax |
erijo
added a commit
that referenced
this issue
Mar 3, 2025
* Silence warnings when collecting alt files (#521) * Adjust handling of encrypt patterns to match 3.3.0 and older * Make encrypt exclude patterns only match encrypted files * Automatically exclude alt and template files (#234) * Support negative alt conditions (#365) * Handle filenames with space in bash completion (#341) * Add new yadm.filename template variable (#520)
This is now available in yadm 3.5.0. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
I'd like to be able to negate a alternate match in the filename
Describe the solution you'd like
I think something like (and I can't believe I'm suggesting the fortran operator, but for shell safety... unless you want to parse unicode https://en.wikipedia.org/wiki/Relational_operator)
and then add it's compatriot for consistency as an alias to the current behavior
of course this could create one problem, what if you have a pattern that has a dot in it, in that case I'd guess you'd have to do 2 things, one maybe make this a toggle feature for now, and if they do toggle it, they have to use the operator if its going to be ambiguous, or they just have to do that period. You could consider then in a next major version whether to deprecate/remove the old behavior.
Describe alternatives you've considered
obviously you can use the if/else/include pattern with a template, but that's kind of cludgy if you want the whole file
The text was updated successfully, but these errors were encountered: