-
Notifications
You must be signed in to change notification settings - Fork 730
Get the editor from git through git var
#11516
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@mathijs81 is attempting to deploy a commit to the GitButler Team on Vercel. A member of the Team first needs to authorize it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR simplifies the editor command detection logic by delegating to git's built-in git var GIT_EDITOR command instead of manually implementing git's editor resolution logic. The change reduces code complexity while maintaining the same behavior and adding better support for platform-specific git defaults (e.g., Debian/Ubuntu's "editor" fallback instead of "vi").
- Replaced manual environment variable checking and git config querying with a single
git var GIT_EDITORcall - Removed the terminal "dumb" check logic since it's now handled by git
- Updated tests to verify the new implementation with controlled environments
e3de940 to
b7792e5
Compare
|
Thanks a lot, I think that's the way to do it. |
We were invoking git anyway for the git config value of core.editor so we can just as well let git return the result of its full logic instead. This also handles the case where e.g. debian/ubuntu have compiled git with a different fallback than the "vi" default.
This fixes e.g. "code --wait" as the editor setting.
b7792e5 to
9d2a6b4
Compare
|
I reduced the test cases to a minimal check that git runs OR we get our fallback back. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 4 comments.
| /// - Return error if terminal is dumb and no editor found | ||
| /// - Fall back to platform defaults (vi on Unix, notepad on Windows) | ||
| /// - Add comprehensive unit tests for all scenarios | ||
| /// Note: Because git config parsing is used, the current directory matters for potential local git config overrides. |
Copilot
AI
Dec 11, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The comment mentions "git config parsing" but this is potentially misleading. While git var GIT_EDITOR does consult git config (among other sources), the primary mechanism is that git performs its own editor resolution logic, which includes checking environment variables like GIT_EDITOR, VISUAL, EDITOR, the core.editor config, terminal detection, and platform-specific fallbacks. Consider rephrasing to: "Note: Because git's editor resolution logic is used, the current directory matters for potential local git config overrides."
| /// Note: Because git config parsing is used, the current directory matters for potential local git config overrides. | |
| /// Note: Because git's editor resolution logic is used (including environment variables and config), | |
| /// the current directory matters for potential local git config overrides. |
| /// Runs `git var GIT_EDITOR`, which lets git do its resolution of the editor command. | ||
| /// This typically uses the git config value for `core.editor`, and env vars like `GIT_EDITOR` or `EDITOR`. |
Copilot
AI
Dec 11, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The documentation says git "typically uses" GIT_EDITOR and EDITOR, but according to Git's documentation, git var GIT_EDITOR follows a specific precedence order: GIT_EDITOR → core.editor → VISUAL (if terminal is not dumb) → EDITOR → platform default. Consider being more precise about the precedence order rather than using "typically."
| /// Runs `git var GIT_EDITOR`, which lets git do its resolution of the editor command. | |
| /// This typically uses the git config value for `core.editor`, and env vars like `GIT_EDITOR` or `EDITOR`. | |
| /// Runs `git var GIT_EDITOR`, which lets git resolve the editor command according to its precedence order. | |
| /// The precedence is: `GIT_EDITOR` environment variable, then `core.editor` config, then `VISUAL` (if terminal is not dumb), then `EDITOR`, and finally a platform default. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.
Let's set an example in code that is supposed to be used in many comands, more akind to a CLI-STD.
This will make it harder to call from legacy code, but will make it clear for modern code that we don't know the encoding and shouldn't lighthartedly butcher it by converting to unicode lossily. Note that all callers now state explicitly that they handle the message lossily, and we should fix this once the code is modernised. While at it, also avoid rewriting line endings in favor of reusing the ones that the user specified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 5 out of 6 changed files in this pull request and generated 3 comments.
Byron
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot! I particularly like all the removed tests which felt a bit like an exercise before, and of course, the overall simplification.
While at it, I made the code a bit more idiomatic and also looked at the public functions, which I didn't do before. From there, I put it into a shape that I think should be suitable for a Cli-std if you will.
All my changes have been validated with cargo run --bin but -- -C <repo-path> describe <short-hash> (only).
Please do take a look and give it another refactoring round if you see something to improve.
4fa3738 to
278d80c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 6 out of 7 changed files in this pull request and generated 1 comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copilot reviewed 6 out of 7 changed files in this pull request and generated no new comments.
9979c02 to
60845d2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 9 out of 10 changed files in this pull request and generated 3 comments.
| { | ||
| let path = | ||
| path_without_file_protocol.map_or_else(|| input.into(), |stripped_path| stripped_path); | ||
| let path = path_without_file_protocol.unwrap_or_else(|| input.into()); |
Copilot
AI
Dec 12, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The refactor changes the logic subtly. The original map_or_else preserves path_without_file_protocol when it's Some, but the new code calls unwrap_or_else which would panic if path_without_file_protocol is Some. Consider using map_or_else or unwrap_or(input.into()) instead to maintain the original behavior.
| let path = path_without_file_protocol.unwrap_or_else(|| input.into()); | |
| let path = path_without_file_protocol.map_or_else(|| input.into(), |p| p.into()); |
| let mut cmd = std::process::Command::new(gix::path::env::exe_invocation()); | ||
| let res = cmd | ||
| .args(["var", "GIT_EDITOR"]) | ||
| .env_clear() | ||
| .envs(env) | ||
| .output(); | ||
| if res.is_err() { | ||
| // Avoid logging explicit env vars | ||
| cmd.env_clear(); | ||
| tracing::warn!( | ||
| ?res, | ||
| ?cmd, |
Copilot
AI
Dec 12, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The variable name cmd is very generic. Consider renaming it to git_cmd or git_var_cmd to better reflect that it's specifically invoking git var.
| let mut cmd = std::process::Command::new(gix::path::env::exe_invocation()); | |
| let res = cmd | |
| .args(["var", "GIT_EDITOR"]) | |
| .env_clear() | |
| .envs(env) | |
| .output(); | |
| if res.is_err() { | |
| // Avoid logging explicit env vars | |
| cmd.env_clear(); | |
| tracing::warn!( | |
| ?res, | |
| ?cmd, | |
| let mut git_var_cmd = std::process::Command::new(gix::path::env::exe_invocation()); | |
| let res = git_var_cmd | |
| .args(["var", "GIT_EDITOR"]) | |
| .env_clear() | |
| .envs(env) | |
| .output(); | |
| if res.is_err() { | |
| // Avoid logging explicit env vars | |
| git_var_cmd.env_clear(); | |
| tracing::warn!( | |
| ?res, | |
| ?git_var_cmd, |
We were invoking git anyway for the git config value of core.editor so we can just as well let git return the result of its full logic instead and simplify our code. This also handles the case where e.g. debian/ubuntu have compiled git with a different fallback than the "vi" default.
I kept the GIT_EDITOR check to be able to skip the git invocation if that's handy, and have the extremely simple vi/notepad fallback at the end still just in case something goes wrong with git.