constantly upgrading

[amitu]

constantly upgrading

[Qix-]

Haha alright 👍 Combative tone noted.

[calebcartwright]

Thanks for the report. Could you share the version of the hook file as well? You can find it in the comment at the top of any of the files (e.g. git/hooks/pre-commit)

[amitu]

Interesting: # version 0.12.0. I first used Github reference in the Carog.toml to use version 0.12 (wanted more than one command for hooks).

I moved to the crates version after I saw this problem in Github(master/main) version.

Also "Remove the git hook scripts that were placed in the git hooks directory in your local project workspace" in README.md is a "meta-statement", as in how am I supposed to know what all hooks were placed by rusty-hook. My guess is all hooks were placed by rusty-hook, so README should say so, or maybe give some grep-based statement to delete all hooks placed by this command.

[amitu]

Deleting hooks cd .git/hooks && grep -Ril rusty . | xargs rm and reinstalling 0.11 fixed.

[calebcartwright]

Interesting: # version 0.12.0. I first used Github reference in the Carog.toml to use version 0.12 (wanted more than one command for hooks).

I moved to the crates version after I saw this problem in Github(master/main) version.

Yup, that's the issue in your environment.

You can always run more than one command with &&, it's the array-style syntax support that's only available in 0.12 (this is admittedly ambiguous in the readme section so we'll update that).

Also "Remove the git hook scripts that were placed in the git hooks directory in your local project workspace" in README.md is a "meta-statement", as in how am I supposed to know what all hooks were placed by rusty-hook. My guess is all hooks were placed by rusty-hook, so README should say so, or maybe give some grep-based statement to delete all hooks placed by this command.

Sorry but I don't fully agree with your perspective here. We have an open issue to track the implementation of an auto-cleanup feature (refs #5). In the absence of tooling-driven removal, cleanup/removal is a human process today. I guess it wouldn't hurt to remind users that the way git hooks work is by having a file for each hook, so yes, rusty-hook initialization creates the hook files. However, at the same time neither we as maintainers nor our documentation are aware of the contents of any files or directories on a user's file system, e.g. even a hook file originally created by rusty-hook could have been replaced by another tool or manually by the user themselves.

Deleting hooks cd .git/hooks && grep -Ril rusty . | xargs rm and reinstalling 0.11 fixed.

Thanks for sharing!

Going to go ahead and close this given the resolution, but please let us know if you have any other questions!

[Qix-]

Not really sure that downgrading is a solution here. Not only do I need to pull 0.12.0 from git since it's not on crates.io, but it has to "upgrade" every single time I commit. Downgrading does indeed "fix" this issue but that shouldn't be the solution.

[calebcartwright]

Not really sure that downgrading is a solution here. Not only do I need to pull 0.12.0 from git since it's not on crates.io, but it has to "upgrade" every single time I commit. Downgrading does indeed "fix" this issue but that shouldn't be the solution.

I'm a bit surprised by this @qix given that you commented on #171 where we'd previously shared that users should unequivocally never install this package from source.

As stated in #171, the only supported releases and installation processes for this package are via crates.io. The only user-facing, unreleased change that exists in source control is the ability to use array syntax for multiple commands instead of having to use && chaining.

I.e. in the released versions, one can run multiple commands like this:

# v0.11
pre-commit = "cargo test && cargo clippy"

and the unreleased, imo minor, change is the ability to use array syntax if you prefer:

# unreleased, unsupported
# v0.12
pre-commit = ["cargo test", "cargo clippy"]

While I understand the reasoning behind why some have a preference for the array syntax, I do not view that as adequate justification to install a tool in an unsupported manner that the project have maintainers have explicitly said to avoid. If folks are going to decide to disregard that direction and do it anyway, then I think they have to be prepared for things to accordingly break.

Essentially, we've said "do not do X", as well as "well you weren't supposed to do X, but if you did, here's how you can undo that mistake". While I appreciate the side effects and "undo" process aren't the most pleasant, I fundamentally believe that it is not incumbent upon the project to invest time and energy into streamlining the process to undo something that we've said shouldn't have been done in the first place.

I will take a look at trying to make some of the opening docs more clear and explicit on this front, and hopefully one day bindep support in cargo will be stabilized and allow us to simplify things and eliminate the exclusive-crates.io-install constraint.

For now though, this is way things are.

[Qix-]

and the unreleased, imo minor, change is the ability to use array syntax if you prefer:

While I understand the reasoning behind why some have a preference for the array syntax,

It's not a preference. It's the fact that && is not a valid syntax in all shells.

I will take a look at trying to make some of the opening docs more clear and explicit on this front, and hopefully one day bindep support in cargo will be stabilized and allow us to simplify things and eliminate the exclusive-crates.io-install constraint.

Perhaps a release can just be cut...?

[calebcartwright]

It's not a preference. It's the fact that && is not a valid syntax in all shells.

Would you mind doing me a favor and opening up a new issue with steps to reproduce? Specifically, where there's a rusty-hook error displayed as a result of invoking a git commit that results in rusty-hook attempting to execute a hook containing && (not just manually running the hook command contents directly in a shell).

Much like various utilities that ship with git itself (e.g. subtrees), rusty-hook always executes the specified hook commands in a posix-compliant shell where and_if is always fully supported. This is something we've tested rather extensively, but if there's something we've missed it'd be great to know!

[calebcartwright]

Haha alright 👍 Combative tone noted.

I apologize if something in my prior comment came across this way, as this was absolutely unintended.

You've implied that there's some potentially buggy behavior which is a far bigger consideration than the topic of this closed issue. I expressed why I didn't think that behavior should be occurring 🤞 I also asked if you'd be willing to share more info, in a new issue, so that we can take a closer look and keep track of it if we're able to repro.

I genuinely do not see any negative connotations in that ask, nor in the way the ask was phrased, and certainly not as combative.

At the same time and in the same vein, I'd (rhetorically) ask you to consider whether you feel the same is true for some of your comments, e.g.:

Perhaps a release can just be cut...?

Haha alright 👍 Combative tone noted.

These are coming across as rather flippant to me, though perhaps this was similarly unintentional from your end.