choose_merge_request crashes on detached HEAD

[seflue]

Prerequsities

• I'm on the latest version of the plugin
• I've installed the required dependencies
• I've run :h gitlab.nvim.troubleshooting and followed the steps there

Setup Configuration and Environment

Default configuration; no environment variables relevant to this path.

Bug Description

choose_merge_request() crashes when the working tree is in detached
HEAD (or in a fresh repo without commits):

.../lua/gitlab/git.lua:112: attempt to concatenate local 'err' (a nil value)
stack traceback:
  .../lua/gitlab/git.lua:112: in function 'get_current_branch'
  .../lua/gitlab/actions/merge_requests.lua:33: in function 'cb'

git branch --show-current returns an empty string with exit code 0
in that case, so err is nil and the error branch in git.lua:112
concatenates nil into the notify message.

The only caller of get_current_branch() in this flow is
merge_requests.lua:33, which uses the return value to skip a
clean-tree check and a no-op switch_branch when the user is already
on the source branch, so detached HEAD has no semantic meaning here
beyond the crash itself.

Happy to open a PR.

Reproduction Steps

1. Check out an arbitrary commit in detached HEAD mode
2. In Neovim: :lua require("gitlab").choose_merge_request()
3. Pick any MR → crash

[jakubbortlik]

Hi @seflue, correct me if I'm wrong but to me it seems that this is yet another use case of a MR where there's no local feature branch. There's an existing PR for MRs from a fork. A third use case is what I mention in this note for #546: Opening a closed MR where the feature branch has been deleted.

I'm wondering whether all these use cases could have a common solution rather than creating a separate workflow for each of them. Could you please elaborate on what behaviour you would expect in case of detached HEAD? Do you expect the feature branch to be checked out?

[seflue]

@jakubbortlik Yes, I'd expect the feature branch to be checked out (the existing happy path).

I agree that three separate code paths for "no local feature branch" wouldn't be ideal, but the crash here is orthogonal. It happens before any of the workflow logic runs, in get_current_branch(). Unifying the cases you mentioned can happen in #546 or a follow-up.

I've already created a small fix on a branch, should I open a PR? Showing the code makes it clearer.

[jakubbortlik]

I've already created a small fix on a branch, should I open a PR? Showing the code makes it clearer.

Sure, PRs are welcome! Please read CONTRIBUTING.md, before opening the PR. Just to set the expectations right: I only merge trivial changes into develop. More complex PRs and merging to main are managed by @harrisoncramer.