Skip to main content

Commits > Lines added

Written by Tom Williams

Dataset: Commits from pull requests

Entity: Commit

Field ID: additions

Type: Integer

Description: The number of lines of code added in the commit.

Source: App

App Mapping

Github (Commits)

additions

Gitlab (Commits)

N/A: always 0, see below

Bitbucket (Commits)

Cloud

Calculated by summing lines_added on each changed file from the commit diffstats.

Data Center

totalInsertions from the commit diff stats summary

Azure DevOps (Commits)

Calculated from a git-based code diff

Jira

N/A

ClickUp

N/A

Trello

N/A

Why are lines of code not fetched for GitLab?

GitLab does not return the number of lines of code changed when listing the commits of a merge request. To fetch the lines of code per commit, one must make an additional API call per commit.
​
We do it for merge requests because the number of additional API calls remains reasonable (several thousand). However, commits could generate many additional API calls (several tens or hundreds of thousands), which would, in turn, contribute to reaching the GitLab rate limit more quickly, potentially slowing down data imports.
​
So for now, the lines of code per commit are not retrieved for GitLab, and this field is always 0 on GitLab commits. This decision might be revisited later on.

Reporting Use Cases

The Lines added field from the Commits dataset provides a granular, commit-level view of the volume of new code being introduced. It is a powerful numeric field for analyzing individual developer contributions, understanding the nature of changes within a pull request, and creating detailed metrics on coding patterns.

  • Filtering by Commit Size: You can create highly specific reports by filtering commits based on their size.

    • Find Large Commits: Isolate individual commits that might be too large and difficult to review with a filter like Lines added > 500. This can help in coaching developers to commit smaller, more atomic changes.

    • Exclude Scaffolding/Generated Code: If a large, auto-generated file is skewing your metrics for a pull request, you can create a report on that PR and then filter out the specific large commit to get a more accurate picture of the manual coding effort.

  • Analyzing Contribution Patterns: You can aggregate this field to understand the volume of new code being written.

    • Code Volume per Author: A bar chart with Author as the dimension and a SUM(additions) metric will show the total volume of new code each developer has written, providing a different perspective on contribution than just a simple commit count.

  • Custom Formulas for Advanced Analysis: This field is crucial for detailed, commit-level analysis of code health and style.

    • Commit-Level Refactoring Ratio: While usually measured at the pull request level, you can analyze refactoring at a micro level. A list of commits with a custom dimension like ROUND(deletions / IF_ZERO(additions, 1) * 100, 2) can show the refactoring ratio of each individual commit, helping to distinguish between "pure addition" commits and "refactoring" commits within the same PR.

Related Articles
Did this answer your question?