Expand ~ in the worktree creation prompt path#5597
Open
pedrampdd wants to merge 1 commit into
Open
Conversation
When creating a new worktree via the prompt, the user-entered path is passed directly to "git worktree add" via os/exec. Because the command is exec'd rather than run through a shell, "~" is taken literally and git creates a directory called "~" containing the rest of the path, instead of the user's home directory. Add a small helper utils.ExpandHomeDir that turns a leading "~" or "~/" into the user's home directory (using os.UserHomeDir) and apply it to the path captured by the New worktree path prompt. Paths that do not begin with "~" are returned unchanged, so absolute paths and relative paths like "../foo" continue to work the way they did before. The "~user" form is rejected explicitly so we don't silently do the wrong thing. Adds a table-driven unit test for the helper covering the empty input, untouched paths, "~" alone, "~/foo/bar", "~user/foo", and a mid-path "~" segment. Fixes jesseduffield#4708
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #4708.
The bug
When creating a new worktree from the worktree prompt and entering a path that begins with
~(e.g.~/code/feature-x), lazygit creates a directory literally called~inside the repo, e.g.<repo>/~/code/feature-x. The~is meant to expand to the user's home directory the way it does in shells.Root cause
The user-entered path flows from the
New worktree pathprompt (pkg/gui/controllers/helpers/worktree_helper.go) intoWorktreeCommands.New, which buildsgit worktree add <path> <base>and runs it viaos/exec.os/execdoes not invoke a shell, so~is taken literally. This was confirmed in the issue thread (cc @ChrisMcD1, @stefanhaller).The fix
Adds a small helper
utils.ExpandHomeDir(per @stefanhaller's suggestion to put the logic inpkg/utils/) that expands a leading~or~/toos.UserHomeDir(). Other paths — absolute paths,../foo(which already worked because git resolves relative paths against cwd), or paths with a non-leading~— are returned unchanged. The~userform is rejected explicitly so we don't silently do the wrong thing.The helper is applied at the prompt's
HandleConfirmcallback so the expanded path is what flows through the rest of the worktree creation pipeline.Tests
pkg/utils/path_test.gocovering: empty input, untouched relative path, untouched absolute path,~alone,~/foo/bar,~user/foorejection, and a mid-path~segment.pkg/utils/...,pkg/gui/controllers/helpers/...,pkg/commands/...).go build ./...succeeds.I deliberately scoped this to home-directory expansion — env var expansion (
$HOME/...) is a larger surface area and the issue thread converged on~specifically.