Skip to content
This repository has been archived by the owner on Jun 19, 2023. It is now read-only.

'export' fails in 'gitflow_load_settings()' when the repo is in a directory structure which contains spaces #148

Closed
craigfowler opened this issue Feb 17, 2014 · 0 comments

Comments

@craigfowler
Copy link
Contributor

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants