You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 19, 2023. It is now read-only.
If the current repository resides within a directory structure which contains spaces, the command export GIT_CURRENT_REPO_DIR=$(git rev-parse --show-toplevel 2>/dev/null) in the function gitflow_load_settings() (in gitflow-common) fails with an error.
Here is a fairly simple test case, the error occurs on the last line, after I issue the git flow release start 1.0.0 command. For the record I am running Debian Wheezy and my default shell is bash. I can reproduce this on the latest stable release as well as on the develop branch.
craig@craig-laptop:~/Projects$ mkdir -p "Dirname-with-a space/example.com"
craig@craig-laptop:~/Projects$ cd"Dirname-with-a space/example.com/"
craig@craig-laptop:~/Projects/Dirname-with-a space/example.com$ git flow init
Initialized empty Git repository in /home/craig/Projects/Dirname-with-a space/example.com/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [production]
Branch name for"next release" development: [master]
Hooks and filters directory? [.git/hooks]
craig@craig-laptop:~/Projects/Dirname-with-a space/example.com$ git flow release start 1.0.0
/usr/local/bin/git-flow: 295: export: space/example.com: bad variable name
Looking at this, it appears that the error is only being raised by the shell when the remainder of the path contains characters which would be illegal as a variable name. This suggests that there is a larger issue in that the export command in git-flow is potentially incorrectly setting the GIT_CURRENT_REPO_DIR variable. If there are no characters which are illegal as variable names in the remainder of the path (after the space) then the export command would not raise an error but would silently assign an incorrect/unintended value. This assignment could then (as comments suggest) perhaps be overridden in some way - hiding the bug entirely.
The solution appears simple: Quote the value to export into the GIT_CURRENT_REPO_DIR environment variable.
The text was updated successfully, but these errors were encountered:
If the current repository resides within a directory structure which contains spaces, the command
export GIT_CURRENT_REPO_DIR=$(git rev-parse --show-toplevel 2>/dev/null)
in the functiongitflow_load_settings()
(ingitflow-common
) fails with an error.Here is a fairly simple test case, the error occurs on the last line, after I issue the
git flow release start 1.0.0
command. For the record I am running Debian Wheezy and my default shell is bash. I can reproduce this on the latest stable release as well as on the develop branch.Looking at this, it appears that the error is only being raised by the shell when the remainder of the path contains characters which would be illegal as a variable name. This suggests that there is a larger issue in that the export command in git-flow is potentially incorrectly setting the
GIT_CURRENT_REPO_DIR
variable. If there are no characters which are illegal as variable names in the remainder of the path (after the space) then the export command would not raise an error but would silently assign an incorrect/unintended value. This assignment could then (as comments suggest) perhaps be overridden in some way - hiding the bug entirely.The solution appears simple: Quote the value to export into the
GIT_CURRENT_REPO_DIR
environment variable.The text was updated successfully, but these errors were encountered: