Skip to content
This repository

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

Closed
wants to merge 4 commits into from

5 participants

Michael Hart Steffen Jaeckel Jack Whitehead Vincent Driessen Niklas Hansen
Michael Hart

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.

Michael Hart mhart referenced this pull request November 05, 2011
Closed

Useable with MSysGit? #25

Steffen Jaeckel

+1 to be integrated soon for msysgit users!

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

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.

Vincent Driessen Owner
nvie added a note November 23, 2011

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

Vincent Driessen Owner
nvie added a note November 23, 2011

...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
Michael Hart

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.

Jack Whitehead

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

Vincent Driessen
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?

Michael Hart

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

Jack Whitehead

@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

Michael Hart

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

Michael Hart

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

Jack Whitehead

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.

Jack Whitehead

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.

Michael Hart

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?

Jack Whitehead

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

Michael Hart

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.

Jack Whitehead

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

Michael Hart

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

Jack Whitehead

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

Vincent Driessen
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
Jack Whitehead

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.

Vincent Driessen
Owner

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

Jack Whitehead

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

Vincent Driessen
Owner

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

Vincent Driessen nvie closed this December 01, 2011
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 1 changed file with 6 additions and 1 deletion. Show diff stats Hide diff stats

  1. 7  git-flow
7  git-flow
@@ -42,7 +42,12 @@ if [ "$DEBUG" = "yes" ]; then
42 42
 	set -x
43 43
 fi
44 44
 
45  
-export GITFLOW_DIR=$(dirname "$0")
  45
+if [[ $OS == Windows* ]]; then
  46
+	export GITFLOW_DIR=$(dirname "${0//\\/\/}")
  47
+else
  48
+	export GITFLOW_DIR=$(dirname "$0")
  49
+fi
  50
+
46 51
 
47 52
 usage() {
48 53
 	echo "usage: git flow <subcommand>"
Commit_comment_tip

Tip: You can add notes to lines in a file. Hover to the left of a line to make a note

Something went wrong with that request. Please try again.