Skip to main content

Automatically exclude cherry-pick, revert and rebase from statistics

An enabled Off/On toggle makes commits recognized as a cherry-pick, revert or rebase not count toward Calories and Lines or Retention, so the same work (moved from another branch, reverted, recreated) is not counted toward statistics more than once.

Recognition rules​

Every commit gets one of four classifications: normal, revert, cherry-pick or rebase duplicate. Recognition works independently of the toggle, so the classification is always recorded; the toggle only decides whether a duplicate drops out of statistics.

ClassificationWhat the recognition is based on
Revertthe line This reverts commit <identifier>, which Git appends to the message on git revert. It is the message body that counts, not its first line.
Cherry-pickthe annotation cherry picked from commit <identifier>, which Git appends on git cherry-pick -x.
Rebase duplicatecomparison against already counted commits: the same repository, the same author, the same authoring timestamp and the same set of changed files. File paths are compared, not their content.

The first two rules read only the commit message. The third is the only one that compares a commit against history, and it is the one that catches identifiers rewritten after a rebase or force push, where no annotation is created.

Limits of this mechanism​

They explain results that look like a bug:

  • A revert written by hand will not be recognized. Reverting changes without Git's annotation, for example via git revert --no-commit and a custom message, is, to Q247, an ordinary commit.
  • A cherry-pick without the -x flag leaves no annotation. It will only be caught by the third rule, and only when the author, timestamp and set of files match.
  • A rebase that changes the authoring timestamp (for example via git commit --amend) creates a commit that the third rule will not associate with the original.
  • Only the revert itself is excluded, the reverted commit stays. Work that was reverted is therefore counted once, not zero times.
  • Two different commits by the same author, with the same timestamp and the same set of files, will be treated as a duplicate. This happens with script-generated commits or mass formatting.
  • A manual decision takes precedence. A commit manually included in statistics stays in them regardless of classification, as described in the section below.
Toggling recalculates data gradually

Changing the toggle does not rewrite all commits at once. Q247 fills them in, in batches, in the background, so on a large organization the statistics change over several successive passes, not immediately after saving. Retention changes at the same pace.

This toggle saves immediately

There is no save button here and no confirmation prompt. Clicking it immediately changes how statistics are calculated for the whole organization.

Excluding a single commit​

Beyond the automatic rule, a specific commit can be excluded. This action takes place outside Configuration: in the commit details window, opened from the increment list on the Project, Team and Participant pages. The window has a two-state toggle, "Exclude from statistics" and "Include in statistics", so the decision can be reversed at any time.

Permissions for this action differ from the permissions for the other settings on this tab. A commit can be excluded from statistics and restored by:

  • the team manager of the team the commit author belongs to, or of a parent team in the tree,
  • the manager of the root of the team tree, for any commit in the organization,
  • the project manager of the project the commit comes from,
  • the manager of a team assigned to the project,
  • the manager of the team the project manager belongs to.

The manager of the commit author's team and the manager of a parent team have this action in every project, including one they have no access to themselves. The team manager is the Manager team role, described in Permissions.

The Viewer project access level, the regular project participant and the team member do not grant this action on their own. Neither does the Admin role, which does not open access to business data: an administrator without one of the roles on the list will not see the action. Q247 checks availability for each commit separately: when the window shows several commits, the toggle may appear for only some of them. The full breakdown is described in Permissions.

The exclusion applies to a single commit and covers all metrics calculated from its content: Calories, Increments and Lines and everything derived from them.

A commit restored with the "Include in stats" action also counts toward Retention and the R30 indicator in the AI Adoption panel. A manual decision does not, however, override an exclusion by file patterns.

The Retention columns and the R30 indicator in AI Adoption show the change after the commit details window is closed, while the other table columns, for example Calories, show it after the next recurring background recalculation.

See also​