vouch

Related: https://github.com/mitchellh/vouch/issues/21 Disclaimer: Maybe I am using vouch incorrectly. You tell me. What I want to do: I want to track people who did not follow the rules of a project and prevent them to contribute in some kind of ladder: "First warning" -> "Temporary ban" -> "Permanent ban". For that, I intended to use vouch, and use the denounce feature: "First warning" gets a commented out line "Temporary ban" gets the actual line "Permanent ban" is In my example, would at least look like a link pointing to the violation warning; would at least look like two links, would at least look like 3 links. I would like to track dates of those events uncorrelated from the git commits who introduced the ban. In other words, regardless whether: I am busy and forgot to put the temp ban in my vouch file I got a policy in place but did not use vouch yet .. I would like to start to use vouch and reference to past or future dates. I know it is possible to see (with ) when the temporary ban was issued. Technically, it would be possible to automate when to unban from the git blame (by periodically checking the line and appending ). And I know I could create n commits (one for each event) and manipulate their date, but it seems convoluted. However, decorrelating from git makes practical sense to me. I know it's also possible to use the comment field (as it is free text) for storing that date. However, if we are to introduce the feature of _adding a date_ as top level citizen, it would become a standard (before or after the comment?), so multiple projects behave it the same way, and project don't have to remember the syntax to use for their comments ("was it date before link or the other way around? Oh damn I have to check first" syndrome). This date could be present on all command calls by default for example. This still gives the freedom to the projects to see how they will use the date. In my case, it would be the declared date, but it could as well mean an expiry date. Happy to pick your brain on the global relevance of introducing dates as first level citizen.

Looks like https://github.com/suzuki-shunsuke/pinact/pull/1558 is giving us issues on our Vouch action in Ghostty: According to the aforementioned issue, it looks like we're going to have to start tagging versions to ensure they pass pinact. There was a proposal to add branch comments, but it looks like it was ultimately closed as not planned for the time being. This probably means we'll need to tag new changes going forward too when we want to bump vouch in Ghostty. PS: Looks like we could add an ignore rule, but I'd imagine getting into the habit of doing this would not be in the right spirit of checking pins in the first place. 🙂

Fixes #94. The setup-vouch wrapper was using Bash to build a Nushell command string. That escaping is shell-specific, so multi-word values such as custom commit messages or denounce reasons can be split or misparsed before reaching the Nushell command. This changes the wrapper to quote arguments as Nushell double-quoted literals only when needed, while leaving command names and flags bare. It also escapes the resolved path before embedding it in the statement. Verification: local wrapper smoke test with , confirming the full reason was written as one value no-argument wrapper smoke test still prints usage