Use gix in operating_mode and avoid panic

[krlvi]

Motivation

• Avoid panics from unwrapping the legacy git2 repository.
• Unify HEAD inspection to gix so operating_mode can fail gracefully.

Description

• gitbutler_operating_modes::operating_mode now uses ctx.repo.get() (gix) instead of ctx.git2_repo.get().unwrap().
• All failure paths return OperatingMode::OutsideWorkspace (no panics). If the repo handle can't be opened/borrowed, we return OutsideWorkspaceMetadata::default() directly.
• HEAD/ref inspection uses gix (head().referent_name()) and compares against OPEN_WORKSPACE_REFS / EDIT_BRANCH_REF via byte-wise comparisons.
• Minor cleanup: factor repeated OutsideWorkspace construction into a local helper and avoid redundant metadata computation when repo access already failed.

Files:

• crates/gitbutler-operating-modes/src/lib.rs

Regression coverage added:

• Fallback when the repo cannot be opened (.git removed).
• Fallback when on gitbutler/edit without edit-mode metadata.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
gitbutler-web	Ignored	Preview	Feb 16, 2026 5:46pm

[Copilot]

Pull request overview

This PR updates gitbutler_operating_modes::operating_mode to use the gix repository from but_ctx::Context instead of unwrapping the legacy git2 repo, preventing panics and allowing the function to fail gracefully.

Changes:

• Replaced ctx.git2_repo.get().unwrap() with ctx.repo.get() and added graceful fallback to OperatingMode::OutsideWorkspace on failure.
• Switched HEAD reference name inspection/comparisons to gix (referent_name() + byte-wise comparisons) for workspace/edit branch detection.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

[Caleb-T-Owens]

@krlvi I just want to make sure I understand the problem we're solving here.

It looks like the function may be getting called in cases where there isn’t a git repository. If that’s the case, I’m not sure returning OperatingMode::OutsideWorkspace makes the most sense.

Also, with hindsight, unwrapping here seems like a bad idea, so we should probably refactor it to be a Result type.

Would it make sense to update the return type to Result<Option<OperatingMode>>, where Ok(None) represents the absence of a repository? Or would it be cleaner to introduce a NoRepository operating mode instead?

WDYT?

[krlvi]

@krlvi I just want to make sure I understand the problem we're solving here.

It looks like the function may be getting called in cases where there isn’t a git repository. If that’s the case, I’m not sure returning OperatingMode::OutsideWorkspace makes the most sense.

Also, with hindsight, unwrapping here seems like a bad idea, so we should probably refactor it to be a Result type.

Would it make sense to update the return type to Result<Option<OperatingMode>>, where Ok(None) represents the absence of a repository? Or would it be cleaner to introduce a NoRepository operating mode instead?

WDYT?

My objectives were:

• remove the panic
• remove the usage of git2

Happy to change the api, but im wondering if we want to go from OperatingMode to Result<Option<OperatingMode>> 🤷‍♂️
Maybe just a Option<OperatingMode> to represent not having a repo?

But I am also thinking, since "operating mode" is generic enough, maybe there could be a variant for "not a git repo" ?

[Caleb-T-Owens]

@krlvi I just want to make sure I understand the problem we're solving here.
It looks like the function may be getting called in cases where there isn’t a git repository. If that’s the case, I’m not sure returning OperatingMode::OutsideWorkspace makes the most sense.
Also, with hindsight, unwrapping here seems like a bad idea, so we should probably refactor it to be a Result type.
Would it make sense to update the return type to Result<Option<OperatingMode>>, where Ok(None) represents the absence of a repository? Or would it be cleaner to introduce a NoRepository operating mode instead?
WDYT?

My objectives were:

• remove the panic
• remove the usage of git2

Happy to change the api, but im wondering if we want to go from OperatingMode to Result<Option<OperatingMode>> 🤷‍♂️ Maybe just a Option<OperatingMode> to represent not having a repo?

But I am also thinking, since "operating mode" is generic enough, maybe there could be a variant for "not a git repo" ?

I think it would be helpful to refactor this to return a result while we're looking at it. I'm happy to take this on if you'd like.

After giving it some thought, I like the idea of using an OperatingMode variant to represent a missing repo.

[krlvi]

@krlvi I just want to make sure I understand the problem we're solving here.
It looks like the function may be getting called in cases where there isn’t a git repository. If that’s the case, I’m not sure returning OperatingMode::OutsideWorkspace makes the most sense.
Also, with hindsight, unwrapping here seems like a bad idea, so we should probably refactor it to be a Result type.
Would it make sense to update the return type to Result<Option<OperatingMode>>, where Ok(None) represents the absence of a repository? Or would it be cleaner to introduce a NoRepository operating mode instead?
WDYT?

My objectives were:

• remove the panic
• remove the usage of git2

Happy to change the api, but im wondering if we want to go from OperatingMode to Result<Option<OperatingMode>> 🤷‍♂️ Maybe just a Option<OperatingMode> to represent not having a repo?
But I am also thinking, since "operating mode" is generic enough, maybe there could be a variant for "not a git repo" ?

I think it would be helpful to refactor this to return a result while we're looking at it. I'm happy to take this on if you'd like.

After giving it some thought, I like the idea of using an OperatingMode variant to represent a missing repo.

Okay feel free to take over this thing but only if you have the bandwidth for it (i.e. it's not interfering with the rebase engine stuff). If you wanna take it, just close this PR

[krlvi]

ping @Caleb-T-Owens how should we do here?