Skip to main content

commit_messages_in_range

Function commit_messages_in_range 

Source
pub fn commit_messages_in_range(
    root: &Path,
    since: &str,
    include_merges: bool,
) -> Result<Option<Vec<CommitRecord>>, CommitRangeError>
Expand description

Enumerate commits reachable from HEAD but not from since, i.e. the standard <since>..HEAD range, oldest first.

since is anything git rev-parse accepts: a 40-char SHA, an abbreviated SHA, a branch (origin/main), a tag (v1.2.3), or a relative ref (HEAD~5).

include_merges controls whether merge commits in the range are returned. Defaults to false at the call site for PR workflows (where the merge commit at HEAD is the synthetic actions/checkout-produced one) but the caller decides.

Returns:

  • Ok(Some(records)) on success. The vec may be empty if the range itself is empty (since == HEAD on a force-push PR, or no non-merge commits in the range).
  • Ok(None) if git isn’t on PATH or root isn’t inside a git repo. Matches the advisory posture of the rest of this module; rules that consult this helper silently no-op in non-git settings.
  • Err(CommitRangeError::BadRange) if git is present and the repo is valid but the range couldn’t be resolved. Rules surface this as a hard error so the user sees the misconfiguration instead of a confused empty range.

Implementation note: uses --format=%h%x00%B%x1e so the SHA and the message are NUL-separated (NUL never appears in either) and commits are RS-separated (RS = U+001E, “record separator”, which also doesn’t appear in well-formed commit text). The compound encoding is robust against commit messages containing arbitrary text — including em dashes, blank lines, and Unicode shenanigans — without resorting to fragile line-counting.