gitlab_remote rebase sha different that source branch rebased sha. Comparison faiure

Configuraton

marge-bot configuration set to use gitlab_rebase fusion type (rebase_remotely = true). It is configured to run marge bot job on gitlab runner and use publicly accessible gitlab instance: https://gitlab.com in version GitLab Enterprise Edition 17.7.0-pre 5393d126495

How current implementation works

Let's assume that merge request branch requires rebasing with target branch. During merge request processing MergeJob.update_from_target_branch_and_push function is called. It will detect that fusion strategy is set to gitlab_rebase and will start with local source branch rebasing. When local rebase will finish its exectuion last commit sha from rebased branch will be returned for furter comparison updated_sha. In the next step actual gitlab remote rebase will be performed rebase. When rebase execution will finish merge_request.sha is compared with previously retrieved sha from local source branch rebasing(updated_sha). If values are different exection will raise exception and will try to retry.

How commit sha generation is performed

To explain why problem occurs lets firstly explain how commit sha are generated. Theese are generated based on:

  • Tree hash: The SHA-1 hash of the root tree object, representing the state of the directory and file structure at the commit.
  • Parent commits: If the commit has parent commits (e.g., in the case of merges or sequential commits), their hashes are included.
  • Commit message: The text message describing the changes in the commit.
  • Author information: The name and email address of the author, along with the timestamp of the commit.
  • Committer information: The name, email address, and timestamp of the person who created the commit (can differ from the author in some cases).

What will happen if we rebase same source branch twice with target?

When we will perform rebase of source branch with target barnch we will retrieve verson 1 of sha from last source branch commit. But if we will reset source branch to the initial version(before rebase) and we will perform rebase with target again we will retrieve different sha version 2. It is expected because as described above commit sha is also generated based on timestamp of commiter action.

Error description

And here we came to place where my question sits. Sha of rebasing on local source branch retrieved in updated_sha part will always return different value than value from merge_request rebase. Even if tree, parent, author and committer in the commit object are the same(between localy rebased source branch and merge request source branch) timestamp of committer section will be always different. In result first execton of MargeJob.synchronize_using_gitlab_rebase function is raising exception which will then enforce retry of request processing. What is then the reason for making this comparison? Is it, in current setup anyhow possible to do not fail and SHA to match?

Edited by Arkadiusz Witek