Added check for Windows environment so that we can fix paths

[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.

[sjaeckel]

+1 to be integrated soon for msysgit users!

[NiklasHansen]

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]

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

[nvie]

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

[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]

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]

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]

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]

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