<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "bug" label: - https://gitlab.com/gitlab-org/cli/-/issues/?label_name%5B%5D=type%3A%3Abug and verify the issue you're about to submit isn't a duplicate. ---> ### Checklist <!-- Please test the latest versions, that will remove the possibility that you see a bug that is fixed in a newer version. --> - [x] I'm using the latest version of the extension (Run `glab --version`) - Extension version: `main branch` - [x] Operating system and version: Archlinux, rolling release - [x] Gitlab.com or self-managed instance? N/A - [x] GitLab version (if self-managed) N/A - [x] I have performed `glab auth status` to check for authentication issues - [x] Run the command in debug mode (like `DEBUG=true glab mr list`) and attach any useful output ### Summary <!-- Summarize the bug encountered concisely --> The `git status outputs English messages` and `git status contains expected English phrases` tests in `internal/git/stacked_test.go` fail when using a `.gitconfig` that contains the following: ```toml [status] short = true ``` even when there is nothing to commit. ### Environment <!-- on POSIX system (Linux, MacOS), run bash -c 'printf -- "- OS: %s\n- SHELL: %s\n- TERM: %s\n- GLAB: %s" "$(uname -srm)" "$SHELL" "$TERM" "$(glab --version)"' and replace the following section with the result. If you use non-POSIX system, fill in the section manually: - OS: Your operating system including version and architecture (Windows 11 - AMD64, MacOS Sonoma - ARM64) - SHELL: Your shell (bash, fish, zsh, ...) - TERM: Your terminal emulator (Kitty, Xterm2..) - GLAB: result of running `glab --version` (glab version 1.32.0 (2023-08-18)) --> I'm confident this would happen regardless, but my environment is as follows: - OS: Linux 6.19.11-arch1-1 x86_64 - SHELL: /home/jbowe/.cargo/bin/nu - TERM: screen-256color - GLAB: glab 1.92.0 () <!-- Please include any other information that you believe might be relevant in debugging. For example, you may include a shell framework like oh-my-zsh or other customizations like editing the prompt (PS1, PS2, and others). --> Other: ### Steps to reproduce <!-- How one can reproduce the issue - this is very important --> Create `.gitconfig` file in repo, or home directory, with the above configuration, then run `make check`. ### What is the current _bug_ behavior? <!-- What actually happens --> `git status outputs English messages` and `git status contains expected English phrases` fail, since `git status --short` returns no output when there's nothing to commit. ### What is the expected _correct_ behavior? <!-- What you should see instead --> Successful tests. ### Relevant logs and/or screenshots <!--- Paste the activity log from your command line --> ```plaintext --- FAIL: TestStandardGitCommand_Git_SetsLocale (0.01s) --- FAIL: TestStandardGitCommand_Git_SetsLocale/git_status_outputs_English_messages (0.00s) stacked_test.go:288: Error Trace: /home/jbowe/personal/gitlab-community/gitlab-org/cli/internal/git/stacked_test.go:288 Error: Should be true Test: TestStandardGitCommand_Git_SetsLocale/git_status_outputs_English_messages Messages: Git output should be in English, got: --- FAIL: TestStandardGitCommand_Git_SetsLocale/git_status_contains_expected_English_phrases (0.00s) stacked_test.go:304: Error Trace: /home/jbowe/personal/gitlab-community/gitlab-org/cli/internal/git/stacked_test.go:304 Error: "" does not contain "nothing to commit" Test: TestStandardGitCommand_Git_SetsLocale/git_status_contains_expected_English_phrases Messages: Git status should contain 'nothing to commit' for clean working tree ``` ### Possible fixes <!-- If you can, link to the line of code that might be responsible for the problem --> Relevant line: https://gitlab.com/gitlab-org/cli/-/blob/main/internal/git/stacked_test.go?ref_type=heads#L304 I see two possible routes for fixing this - happy to implement the chosen solution, but would appreciate more feedback on preference: 1. Update the Git command executed to specify `--long`, so output always matches expectations. Based on the content of the failed tests, I'm assuming this would be the preferred solution. 2. Update test to accept short output as well. This would likely mean looking at exit codes rather than words contained in the output.