PR Coding time affected by (squash) merge strategy

[dmiele-bonial]

Hello 👋

As per title, we are experiencing some problems in the PR coding time calculation. Specifically, because we always use to squash our commits before merging into the main branch, the PR coding time is often calculated as 0 (or close to 0).

Currently the PR coding time is calculated as "PR creation date minus first commit date" and when squashing commits upon merge the "first commit date" will have timestamp > "PR creation date"

1. Is anyone else experiencing this problem?
2. Would you consider to use another timestamp (e.g. branch creation date) if "first commit date" > "PR creation date"?

Thx!

[klesh]

That is odd.
The first commit is selected based on the commit history of the PR, which should NOT be affected by the Squash and Merge operation because squash_commit is stored separately alongside commit history, at least on Gitlab and Github IIRC.

I don't think your problem is caused by the squashing operation.

Are you rebasing and force-pushing the PR before merging? If so, it might be the root cause. The commit history changed after the operation.

[dmiele-bonial]

Hi @klesh , thank you for the reply. Attaching some screenshot to show in details the challenge we are facing.

PR opened on 2025-04-01, updated two times and finally merged two days later on 2025-04-03.

Upon merge the commits were squashed and resulted in only one commit with a timestamp equal to merge date: 2025-04-03

Eventually this PR has 0 hours for coding, pickup and review time. The change_lead_time though seems calculated correctly (2.30 days).

Are you rebasing and force-pushing the PR before merging?
No, we are don't. We simply (in this case renovate) merge using a default bit bucket merge strategy, no force push.

[klesh]

I see—this issue isn't related to the squashing or merge strategy.

If I understand correctly, the coding time is shown as 0 because the time between the first commit and the PR creation is negligible. Since this was handled by a bot, everything happened almost instantaneously, resulting in no measurable coding time.

You'll notice that the First commit author time is correctly recorded as 2025-04-01, which matches the PR creation time.

[dmiele-bonial]

I see, thank you for the clarification, I should have looked at it better.

I have other cases with 0 coding time for PRs opened by devs but I see that the calculation is "correct" in that case:

1. Dev works on their local machine some half day
2. Push first commit and raise PR right after
3. The diff between first commit and the PR open time is in that case close to 0 so I guess there's nothing we can do (maybe only asking Dev to create a branch right a way before starting to code)

Thank you for the support!

[riskpeep]

We are seeing this issue as well.

We're using BitBucket, and, at least for us, we see that most PRs have a pr_coding_time of 0.

We have squash commits turned on.

In BB, when a squash merge is committed, BB updates the commits on the PR and removes the earlier commits and only shows the squash commit.

Dora then, picks up the PR and finds only the commit mentioned in the PR. Interstingly, the other commits ARE mentioned in the comment history for the PR, but Devlake doesn't seem to pick that up.

[riskpeep]

Looking at the BitBucket plugin, it does collect PR comments, but it does NOT collect PR activity logs. The activity logs are where the additional commit information would be.