Connector name: Github

Table name: commit

Column to add: additions, changes, deletions

API documentation link: https://docs.github.com/en/rest/commits/commits?apiVersion=2026-03-10

Additional details: 

In the GitHub connector's data model, the additions and deletions statistics are currently only exposed at the commit_file level, with no equivalent fields at the commit level.
As a result, in order to obtain this statistic, customers are forced to sync the commit_file entity. This entity has a cardinality that is orders of magnitude higher than commit (one or more rows per file per commit, versus one row per commit), which makes syncing it prohibitively expensive purely to obtain a single aggregated metric.
This is inefficient because the aggregated statistic is already available at the commit level directly from the GitHub REST API. The GET /repos/{owner}/{repo}/commits/{ref} endpoint returns a stats object on the commit payload itself:
json"stats": {
"additions": 104,
"deletions": 4,
"total": 108
}

This is returned alongside (and independently of) the files[] array, which carries the same fields at file granularity. In other words, GitHub already computes and exposes both levels of granularity in a single API response — there is no need to reconstruct the commit-level total by aggregating commit_file rows.

Request:
Please expose additions, deletions (and ideally total) directly on the commit entity, sourced from the stats object in the "Get a commit" response, in addition to (not instead of) the existing commit_file-level fields.
This would let customers choose the granularity they actually need: commit-level aggregates for lightweight reporting/dashboards, without being forced into a full commit_file sync whose cost is disproportionate to the value of the single statistic being sought.