Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Added check for Windows environment so that we can fix paths #161

Closed
wants to merge 4 commits into from

5 participants

@mhart

After a recent installation of msysGit (Git-1.7.7-preview20111014.exe), I've found that the path seems to be getting mangled when invoking git-flow, and the following error occurs:

$ git flow init
C:\Program Files (x86)\Git\bin\git-flow: line 68: ./gitflow-common: No such file or directory
C:\Program Files (x86)\Git\bin\git-flow: line 76: ./gitflow-shFlags: No such file or directory

This turns out to be because the GITFLOW_DIR variable is created by using dirname $0 and $0 in this case happens to be a Windows path with backslashes, and so the command just returns '.' instead of the actual path to Git.

This patch checks to see if we're in a Windows environment and if so converts the path accordingly.

@mhart mhart referenced this pull request
Closed

Useable with MSysGit? #25

@sjaeckel

+1 to be integrated soon for msysgit users!

git-flow
@@ -42,7 +42,12 @@ if [ "$DEBUG" = "yes" ]; then
set -x
fi
-export GITFLOW_DIR=$(dirname "$0")
+if [ -n "$MSYSTEM" ]; then

This doesn't detect my system being Windows. That might be because I, when installed MsysGit, chose to only use Windows Command Prompt, and not using the "normal" git bash. So if there is another way of detecting Windows, that detects Windows in both situations, that would probably be better.

@nvie Owner
nvie added a note

What exactly does the $MSYSTEM variable come from here? Is it guaranteed to be set inside all MsysGit shells? Is this documented behaviour?

@nvie Owner
nvie added a note

...because I agree with @NiklasHansen's comment on this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@mhart

OK - didn't realise it was occurring in all shells - I've changed the check to look at the OS environment variable instead - let me know if that fixes the problem.

@dvide

Your latest commit seems to work for me @mhart, on both the normal Windows cmd and on Git Bash. Thanks!

@nvie
Owner

Is the uname command available? Because this is the standard way of detecting OSes on most systems. Could you guys run that command (and uname -a) and see what happens?

@mhart

It's available in Git Bash - shows up as "MINGW32_NT-6.1 etc, etc" for me - not sure about other environments

@dvide

@nvie It's not available on windows. It's there in Git Bash like @mhart says, but unfortunately not if you're just using the normal cmd.exe

@mhart

Happy to change to 'uname | grep -c ^MINGW' (checking $OSTYPE would be the other portable option) - do we need to consider Cygwin, etc though?

@mhart

Ah, sorry @dvide - didn't see your comment.

@dvide

Yeah, the problem is that the msysgit installer adds %ProgramFiles%\Git\cmd to your system PATH, not %ProgramFiles%\Git\bin where the uname.exe resides. It seems like it uses some scripts in the %ProgramFiles%\Git\cmd directory for invoking git and gitk. Otherwise uname would probably work OK.

@dvide

Tested commit 3a52112 on Cygwin and it doesn't seem to cause any problems; though it works on Cygwin without the change anyway. echo $OS on Cygwin still outputs Windows_NT, so it must be running your new code, but I guess it doesn't matter because there aren't any backslashes in the paths. GITFLOW_DIR ends up as /usr/local/bin in my tests regardless. Thinking about it, is there any need for an if at all in then? We don't need to detect OS; it will just replace any backslashes IF they exist. If they don't exist, no harm done. So might just be OK to use export GITFLOW_DIR=$(dirname "$(echo $0 | sed -e 's,\\,/,g')") for all cases?

Also OSTYPE isn't available on the standard Windows terminal either.

@mhart

Considering that you can't create a file with a backslash in the name on Windows anyway (even Cygwin won't deal with it: http://www.cygwin.com/cygwin-ug-net/using-specialnames.html), it should be fine... no?

@dvide

@mhart Are you allowed backslashes in names on normal non-cygwin unix? If so, I think it's probably best to keep the windows OS detection then.

@mhart

Yeah - I wasn't suggesting getting rid of the detection - just that the slash replace should work on any Windows shell regardless, without messing with filenames any more so than the shell itself would.

@dvide

@mhart That's correct yes. Sorry for the confusion. I was the one suggesting to get rid of the detection, but I didn't realize you could have backslashes in names on other OSes so scratch that. But you're right that on Cygwin, even with your new code it doesn't cause any issues there anyway, so that's nice to know.

@mhart

Just cleaned up the check/replace - @dvide, let me know if that still works for you

@dvide

@mhart, Tested bcf1dfa on Git Bash, normal cmd.exe, and Cygwin. Seems to work fine on all three. I did a git flow init, created a feature branch, merged it back to develop branch. No problems.

Though if I edit git-flow to echo $GITFLOW_DIR, I'm getting this: C:\/Program Files (x86)\/Git\/bin\

Not sure if that was intended, but like I say, it still seems to work for me anyway.

@nvie
Owner

If we can safely find a way that works on all platforms, I'm fine to avoid the OS-detection and just always replace backslashes as Unix users are unlikely to run into troubles with this, and at the same time we're helping out all Windows users.

Please take a look a my proposal here: develop...feature/convert-slashes

Will this do the trick for all of you? If it works, it has the best of a few advantages:

  • It solves the current slash issues on Windows
  • It does not bother our Unix users (likely)
  • It does not depend on OS-detection
  • It does not assume any non-sh shell (like bash, zsh, etc.)
  • It's a single line of code
@dvide

Hi @nvie, your proposal 4b9545e5 doesn't seem to work compared to 3a52112.

Jack@BAKLAVA ~/projects/test
$ git flow init -d
dirname: too many arguments
Try `dirname --help' for more information.

C:\Program Files (x86)\Git\bin\git-flow: line 70: /gitflow-common: No such file or directory
C:\Program Files (x86)\Git\bin\git-flow: line 78: /gitflow-shFlags: No such file or directory

3a52112 produces the appropriately transformed path: C:/Program Files (x86)/Git/bin

It must be the space in the path the produces two arguments to dirname. That's why the quote marks are where they are in 3a52112.

@nvie
Owner

Hi @dvide, I've updated my patch. Can you test it again?

@dvide

@nvie That works fine yeah. Tested it again on all three.

@nvie
Owner

OK, then I'm closing this issue and go for the proposed solution. Thanks for your patience, all ;)

@nvie nvie closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
This page is out of date. Refresh to see the latest.
Showing with 6 additions and 1 deletion.
  1. +6 −1 git-flow
View
7 git-flow
@@ -42,7 +42,12 @@ if [ "$DEBUG" = "yes" ]; then
set -x
fi
-export GITFLOW_DIR=$(dirname "$0")
+if [[ $OS == Windows* ]]; then
+ export GITFLOW_DIR=$(dirname "${0//\\/\/}")
+else
+ export GITFLOW_DIR=$(dirname "$0")
+fi
+
usage() {
echo "usage: git flow <subcommand>"
Something went wrong with that request. Please try again.