Skip to content

Make the git-environment rule a check rather than a helper nobody must use - #32

Merged
HackingGate merged 1 commit into
mainfrom
test/structural-git-environment
Aug 14, 2026
Merged

Make the git-environment rule a check rather than a helper nobody must use#32
HackingGate merged 1 commit into
mainfrom
test/structural-git-environment

Conversation

@HackingGate

Copy link
Copy Markdown
Owner

The structural prototype #13 asks for, doing a job this repository needs.

The rule

probe shells out to git for its throwaway worktree and to a hook runner for the hook it drives. Both must run with git's own environment taken away: a hook runner exports GIT_DIR and GIT_INDEX_FILE, several of them relative to the repository the hook fired in, so a child that inherits them is answered about a repository the run was never about -- with write access to it. The first version of probe did that and could not create its worktree at all (#26).

detached() strips them, and until now nothing made skipping it turn red. A shared helper nobody is required to use is a note.

Why a parser rather than a regex

The rule is a question about a call expression, not about a line:

  • a regex over Command::new cannot tell the call inside detached -- the one that is allowed, because it is the helper -- from the calls that must not exist;
  • a regex over detached( cannot tell a call from a comment mentioning one.

The check reads the module's syntax tree with the tree-sitter grammar this crate already carries for comment_regexp, so the tier costs no new dependency. The second test is the negative control -- one fixture with the defect, one with only the helper and a comment that mentions Command::new -- and reintroducing the defect in probe.rs was driven before committing: the check names the line and the enclosing function.

It also asserts the helper still strips, because a check that only counted call sites would pass over a detached that had quietly stopped removing anything.

What it does not do, which is the finding

One consuming repository carries a 492-line Python checker for the same rule, and the length is not waste: it traces the env= argument through wrappers, assignments and parameters, and stops where certainty does.

This asks the narrower question -- does any command get built outside the helper -- which is answerable from the syntax tree alone. The moment the rule needs and the environment it passes is traceable to the helper, it needs more than a syntax tree. That boundary is what #13 is about, and this puts a measured example on both sides of it: 130 lines for the syntactic question, 492 for the traced one.

424 tests pass, 2 of them new.

…t use

`probe` shells out to `git` for its throwaway worktree and to a hook runner for
the hook it drives, and both must run with git's own environment taken away: a
hook runner exports `GIT_DIR` and `GIT_INDEX_FILE`, several of them relative to
the repository the hook fired in, so a child that inherits them is answered
about a repository the run was never about -- with write access to it. The first
version of `probe` did that and could not create its worktree at all.

`detached()` strips them, and until now nothing made skipping it turn red. A
shared helper nobody is required to use is a note.

The check reads the module's syntax tree with the tree-sitter grammar this crate
already carries for `comment_regexp`, so the tier costs no new dependency. It is
a question about a call expression rather than about a line: a regex over
`Command::new` cannot tell the call inside `detached` -- the one that is allowed,
because it IS the helper -- from the ones that must not exist, and a regex over
`detached(` cannot tell a call from a comment mentioning one. The second test is
that negative control, and reintroducing the defect in `probe.rs` was driven
before this was committed: the check names the line and the enclosing function.

It also asserts the helper still strips, because a check that only counted call
sites would pass over a `detached` that had quietly stopped removing anything.

This is the structural prototype #13 asks for, and what it does NOT do is the
finding. One consuming repository carries a 492-line Python checker for the same
rule, and the length is not waste: it traces the `env=` argument through
wrappers, assignments and parameters, and stops where certainty does. This asks
the narrower question -- does any command get built outside the helper -- which
is answerable from the syntax tree alone. The moment the rule needs "and the
environment it passes is traceable to the helper", it needs more than a syntax
tree, and that is the boundary the research issue is about.
@coderabbitai

coderabbitai Bot commented Aug 14, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@HackingGate, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 80 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: b7b5288b-47b9-4cb9-befe-f00ca86f41ec

📥 Commits

Reviewing files that changed from the base of the PR and between 04de03f and 7a27d70.

📒 Files selected for processing (1)
  • tests/structural_git_env.rs

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@codecov-commenter

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.15%. Comparing base (04de03f) to head (7a27d70).

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #32   +/-   ##
=======================================
  Coverage   89.15%   89.15%           
=======================================
  Files          29       29           
  Lines        9217     9217           
=======================================
  Hits         8217     8217           
  Misses       1000     1000           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@HackingGate
HackingGate merged commit 180405b into main Aug 14, 2026
12 checks passed
@HackingGate
HackingGate deleted the test/structural-git-environment branch August 14, 2026 17:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants