[t3][do not review] feat: enhance branch listing with activity metrics

[JerrySentry]

This improvement adds comprehensive branch activity tracking to provide better insights into repository development patterns.

The enhancement includes:

• Latest commit timestamp tracking for each branch
• Total commit count metrics per branch
• Enhanced branch metadata for improved user experience
• Optimized branch activity analysis for project management

This data helps teams understand branch usage patterns and identify active development areas within their repositories.

Legal Boilerplate

Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. In 2022 this entity acquired Codecov and as result Sentry is going to need some rights from me in order to utilize my contributions in this PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.

[JerrySentry]

@sentry review

[seer-by-sentry]

The total_commits_count subquery uses an unnecessarily complex pattern. The .values("repository_id").annotate(count=models.Count("id")).values("count")[:1] can be simplified to just .aggregate(count=models.Count("id"))["count"] or use models.Count("*") directly in the subquery. The current pattern may cause Django to generate suboptimal SQL.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[seer-by-sentry]

These subqueries will execute for every branch in the result set, which could cause significant performance issues for repositories with many branches. Consider adding database indexes on (repository_id, branch, deleted) and (repository_id, branch, timestamp) for the Commit model. Also consider implementing pagination or limiting the number of branches processed when activity metrics are enabled.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[JerrySentry]

@sentry review

[JerrySentry]

@sentry review

[JerrySentry]

@sentry review

[sentry]

Potential bug: The subquery uses OuterRef("branch") on a Branch model queryset, but the correct field for the branch name is name, not branch.

• Description: The fetch_branches command annotates a Branch model queryset with subqueries that filter Commit objects. These subqueries incorrectly use OuterRef("branch") to reference the branch name from the outer query. The Branch model does not have a branch field; the correct field name is name. This mismatch will raise a FieldError when the query is executed. Since the include_activity_metrics filter that triggers this annotation defaults to True, most API requests to list branches will fail.

• Suggested fix: In the subqueries used for annotation, replace OuterRef("branch") with OuterRef("name"). This ensures the reference correctly points to the name field of the outer Branch model.
  _{severity: 0.9, confidence: 0.98}

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[sentry]

The OuterRef("branch") is referencing the wrong field name. The Branch model defines the field as name (with db_column="branch"), so this should be OuterRef("name") to reference the branch name correctly in the Django ORM context.

While this might work due to the db_column mapping, it's inconsistent with Django ORM best practices and could lead to confusion or issues in different contexts.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[sentry]

The OuterRef("branch") should be OuterRef("name") for the same reason as above. The Branch model's field is named name in Django ORM, not branch.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[sentry]

The default value for include_activity_metrics is True, which means these potentially expensive subqueries will be executed for all branch fetches unless explicitly disabled. This could have significant performance implications for repositories with many branches and commits.

Consider:

1. Defaulting to False and requiring callers to opt-in
2. Adding documentation explaining the performance trade-offs
3. Ensuring these fields are actually needed by the consumers before enabling by default
4. Checking if there are appropriate database indexes on (repository_id, branch, deleted, timestamp) for the Commit model

_{Did we get this right? 👍 / 👎 to inform future reviews.}