Bitbucket is_first_time can report incorrectly

[mcwarman]

Is there an existing issue for this?

• I have searched the existing issues

Description of the bug

The Bitbucket first time does not report correctly when a user has made a commit in another as well as there first merged contribution.

We had a scenario where a first time contributor wasn't being reported in the change log. Looking into it the Commits API from bitbucket it returns all commits across all branches.

GET /repositories/{workspace}/{repo_slug}/commits/

Returns all commits in the repo in topological order (newest commit first). All branches and tags are included (similar to git log --all).

The user has also made another commit in another branch which was there first commit in the repo, but not there first commit on the branch being released.

Reference: https://developer.atlassian.com/cloud/bitbucket/rest/api-group-commits/#api-repositories-workspace-repo-slug-commits-get

curl https://api.bitbucket.org/2.0/repositories/<org>/<repo>/commits?include=<branch>

Steps To Reproduce

1. New user commits and pushes branch
2. New user commits and pushes branch for second change
3. Merge change from item 2
4. git-cliff --current --context --bitbucket-repo "org/repo"

Expected behavior

The is_first_time value is updated based on users contributions to the current branch (not the repo).

Screenshots / Logs

No response

Software information

• Operating system: WSL - Debian GNU/Linux 12 (bookworm)
• Rust version: N/A
• Project version: 2.6.1

Additional context

I guess the fix is to make the current branch context available in the Remote struct so it can be used in the API call.

git-cliff/git-cliff-core/src/remote/bitbucket.rs

Lines 52 to 58 in 508a97e

	fn url(_id: i64, api_url: &str, remote: &Remote, page: i32) -> String {
	let commit_page = page + 1;
	format!(
	"{}/{}/{}/commits?pagelen={MAX_PAGE_SIZE}&page={commit_page}",
	api_url, remote.owner, remote.repo
	)
	}

[orhun]

Duplicate, see #891

[mcwarman]

I was looking at that one, it could be duplicate, but i think the scenarios are slightly different:

This one refers to commit in repo but not in the release effecting the users is_first_time status.

Where as I believe #891 is when a previous releases logs is_first_time status is effected, by future releases.

[orhun]

Hmm I see, I guess this one is also about using different branches and --current flag. Do you think fixing #891 would affect this in some way as well?

I guess the fix is to make the current branch context available in the Remote struct so it can be used in the API call.

This makes sense, however, we should look into other remotes (GitLab,GitHub,Gitea) to see if it is possible. Any ideas?

[mcwarman]

Looks possible according to the various docs:

I think they're all effected looking at the API documentation GitLab and GitHub is possible less obvious to users as it defaults to the default branch.

GitHub

Looks to default to the "default branch", but wouldn't work for users if they'd expect it to be running in different context.

GET /repos/{owner}/{repo}/commits

Query Parameters
sha SHA or branch to start listing commits from. Default: the repository’s default branch (usually main).

https://docs.github.com/en/rest/commits/commits?apiVersion=2022-11-28#list-commits

GitLab

Looks to default to the "default branch", but wouldn't work for users if they'd expect it to be running in different context.

GET /projects/:id/repository/commits

Query Parameters
ref_name The name of a repository branch, tag or revision range, or if not given the default branch

https://docs.gitlab.com/ee/api/commits.html#list-repository-commits

Gitea

Not entirely clear what the default behaviour is here from the documentation, but its either going to work like GitHub/GitLab or Bitbucket

GET /repos/{owner}/{repo}/commits

Query Parameters
sha SHA or branch to start listing commits from (usually 'master')

https://docs.gitea.com/api/1.20/#tag/repository/operation/repoGetAllCommits

Bitbucket

Returns all commits in the repo in topological order (newest commit first). All branches and tags are included (similar to git log --all).

GET /repositories/{workspace}/{repo_slug}/commits

https://developer.atlassian.com/cloud/bitbucket/rest/api-group-commits/#api-repositories-workspace-repo-slug-commits-get

Alternate endpoint might be better GET /repositories/{workspace}/{repo_slug}/commits/{revision}

https://developer.atlassian.com/cloud/bitbucket/rest/api-group-commits/#api-repositories-workspace-repo-slug-commits-revision-get

[orhun]

Thanks for investigating this further! Then I guess we can add a branch field to the remote and update the API usages 👍🏼

Would you be interested in working on this? My schedule is a bit tight these days (due to approaching EuroRust conference) so I might not get to it until next week.

[mcwarman]

Yeah I'd be interested, I'll try have a look, I created the scenario in the test repo here:

• Commit in other repo effect is_first_status: https://bitbucket.org/mcwarman-playground/git-cliff-readme-example/commits/2b61aa56962e50f64b507589448e04f9bc963c47
• Commit in default branch: https://bitbucket.org/mcwarman-playground/git-cliff-readme-example/commits/655ded3d6587d4d08ddb15054d50302c2ff61a81

[orhun]

Awesome