Authentication issues with Bitbucket

[jpfender]

Hey there,

First of all, thanks for creating this, it looks really promising and exciting.

I'm trying to get my hands dirty and push my first virtual branch to our company's Bitbucket, but I'm encountering an authentication issue.

The toast notification in GitButler states that the push failed with: Project remote authentication error.

In the logs, I can see the following:

2024-02-26T16:16:06.380009Z  INFO push_virtual_branch: gitbutler-app/src/virtual_branches/commands.rs:330: new project_id="dae4b093-bee9-41db-b9c7-70607a822329" branch_id="0fb5129e-719e-4f57-a631-8c6495148cb9" with_force=false
2024-02-26T16:16:07.540105Z  INFO push_virtual_branch: gitbutler-app/src/git/credentials.rs:41: authenticating with bitbucket.org:<my_company>/<my_repo>.git using key <my_key> project_id="dae4b093-bee9-41db-b9c7-70607a822329" branch_id="0fb5129e-719e-4f57-a631-8c6495148cb9" with_force=false
2024-02-26T16:16:07.540211Z  WARN push_virtual_branch: gitbutler-app/src/project_repository/repository.rs:390: git push failed project_id=dae4b093-bee9-41db-b9c7-70607a822329 error=Error { code: -16, klass: 23, message: "authentication required but no callback set" } project_id="dae4b093-bee9-41db-b9c7-70607a822329" branch_id="0fb5129e-719e-4f57-a631-8c6495148cb9" with_force=false
2024-02-26T16:16:07.540447Z  INFO push_virtual_branch: gitbutler-app/src/virtual_branches/commands.rs:330: close time.busy=1.16s time.idle=43.9µs project_id="dae4b093-bee9-41db-b9c7-70607a822329" branch_id="0fb5129e-719e-4f57-a631-8c6495148cb9" with_force=false

I have GitButler set up to explicitly use the ed25519 key I'm normally using to push to Bitbucket.

From the error message, is it certain that this is definitely an authentication issue? I know that our Bitbucket has some pre-receive hooks set up that can reject a push for a couple of reasons, such as not including a JIRA ticket ID in the commit message. I took care of that, but I don't know if there is maybe something else in the push from GitButler that BB might not like, such as the branch name.

Happy to provide as much information on our BB config as I can if necessary!

[Byron]

Thanks for reporting!

As of Version 0.11.3 (20240419.070253), there is a new way of pushing and fetching that just uses the Git binary.

Is this something you could try out?

Maybe using the local SSH key also works now, but if not, the logs would probably provide the best insights into what happened. Thanks for your help.

[akshaybabloo]

@Byron Where is this setting located? Can't seem to find it user preferences or project settings on version 0.12.5

[Byron]

Are you on Windows by any chance? I noticed that on Windows the menu might be hidden. Otherwise it should be the project settings.

If you are on Windows and it's actually not using the Git executable, then it might be some other issue that is maybe solved by manually editing the projects.json file for now.

[akshaybabloo]

Yes, I am on Windows. Is there a git path or a setting for that I have to do? Is there like a "use_git_executable": true thing?

This is what I see

[
  {
    "id": "5b6d547b-1090-4fc9-b174-7149584c2229",
    "title": "<project nam>",
    "description": null,
    "path": "<path>",
    "preferred_key": "systemExecutable",
    "ok_with_force_push": true,
    "api": null,
    "gitbutler_data_last_fetch": null,
    "gitbutler_code_push_state": null,
    "project_data_last_fetch": {
      "fetched": {
        "timestamp": {
          "secs_since_epoch": 1719271865,
          "nanos_since_epoch": 835546400
        }
      }
    },
    "omit_certificate_check": null,
    "snapshot_lines_threshold": null,
    "use_new_locking": false
  }
]

Opened a ticket for it https://github.com/gitbutlerapp/gitbutler/issues/4170

[Byron]

Indeed, it's already set to the correct value, so I'd expect it to try and use the Git executable.

Maybe it falls back to trying with git2, hence the original log message.

Maybe you could try the nightly version, as it will try harder to find the Git executable in default installation locations. And even if that doesn't work, I'd expect the output in the logs to reveal what's happening more clearly.