Pre-push hook does not work when it has a list as value

[placintaalexandru]

Environment Details

• Operating System
  • [ ] Linux
  • [ ] Mac
  • [x] Windows
• Rust Version: 1.58.1
• Rust Release Channel
  • [x] Stable
  • [ ] Nightly
  • [ ] Beta
• Cargo Version: 1.58.0
• rusty-hook Version: 0.11.2

Description

When pre-push hook has as value a list, the hook is rejected with the following message:

Invalid rusty-hook config file
Configured hook command failed
pre-push hook rejected

An example of .rusty-hook.toml that fails is this one:

[hooks]
pre-commit = "echo some pre commit message"
pre-push = ["echo mesg1", "echo msg2"]
post-commit = "echo post commit message"

[logging]
verbose = true

Now, when I use only one command in the pre-push hook, everything works. An example of .rusty-hook.toml that works is this one:

[hooks]
pre-commit = "echo some pre commit message"
pre-push = "echo mesg1"
post-commit = "echo post commit message"

[logging]
verbose = true

[calebcartwright]

Thanks for using the tool and reaching out! I'm going to close however as this is a duplicate of a few other issues (#181, #168, and #151). I think the best description of the behavior can be found in https://github.com/swellaby/rusty-hook/issues/151#issuecomment-805459470 but in short you're trying to use an unreleased feature and will instead need to chain your multicommand hooks with &&.

The array syntax support got stuck behind some other larger unreleased changes, including a breaking change that's blocking the ability to release, and unfortunately I haven't been able to carve out enough bandwidth to sit down to rework all of those.

[knzai]

Perhaps having an unreleased feature in the main readme is gonna continue tripping people up 2 years later?

[calebcartwright]

Perhaps having an unreleased feature in the main readme is gonna continue tripping people up 2 years later?

That is possible. Only time will tell :wink:

Jokes aside, I still think people should refer to the actual documentation on crates.io and/or docs.rs that reflect the version they are using. Avoiding those and looking at source control is always going to be a recipe for potential issues.

That being said, if someone wants to submit a PR to modify the readme snippet then I'd support it. My bandwidth for open source is limited these days and what little I do have is occupied with the 2024 edition currently