This is related to another question I asked recently.
When installing msysgit, the installer presents 3 options related to system path:
Never change windows environment. With this option, you have to use the "bash" shell to work with git.
Add the git\bin directory to the PATH environment variable, but without overriding some builtin windows tools. Fellow stackoverflow-ian Gabe Moothart told me in a comment that this option will make some git operations fail! What are these operations? Should I worry about them?
Same as 2 but override some default system tools. What are these tools? What parts of windows depend on them? and will this hurt in practice?
Another issue has come to my mind, unrelated to the system PATH.
What if I have symbolic links and hard links inside my project directory? Does git know how to deal with these? or, will it suffer from infinite recursion, if say, the directory structure was such that some folder was actually a symbolic link to one of its parents?
You get bash
regardless of which option you pick, the latter options just add methods for using Git outside it.
For the latter options, msysgit adds Windows builds of common Linux utilities to PATH
. This includes find
, kill
and sort
, as well as cp
, ls
, rm
, and about 20-30 others.
The problem with the first 3 (and similar) is that they exist in both OSs and function differently in each.
Not a huge ordeal if you know which one you'll be using, but any applications developed expecting one and getting the other will surely throw a fit.
To prevent the conflict, while still having Git work as expected, you can create a simple batch script that adjusts PATH
only for the session. (e.g., readygit.bat
)
@echo off setlocal set PATH=C:\Git\bin;%PATH% cmd
Adjust C:\Git\bin
accordingly. But, just run this and use Git within the cmd
.
With this, you can use install option 3 and safely remove C:\Git\bin
from your system's PATH
, removing any confusion for Windows apps without confusing Git.
I currently use a similar script with GnuWin apps, including find
.
You may want to be aware that:
All git commands are not still there. On MSysGit1.6.2 early March 2009: archimport, cvsexportcommit, cvsimport, cvsserver, filter-branch, instaweb, send-email, and shell.)
Until MSysGit1.6.2, git-svn was not there (it is now).
The problem was git-svn needed subversion's perl bindings, and you can only build them as dynamically loadable modules. And MSysGit had a perl version that did not support dynamically loadable modules.
All details about MSysGit are best explained in their MSysGitHerald Github wiki
On windows (this is less of an issue on other systems, in my very humble opinion...), you must be VERY aware of crlf issues, and note that (Unless they've changed this in the very latest version of Git, which I believe they may have - or if you're using a very old version of Git), autocrlf is enabled by default, unlike all the other git installations.
Also note that unless you use the very latest version of msysgit, soon to be out this week if I recall correctly from the mailing list, your repository size can not be larger than 2GB, total.
Additionally, Windows is wierdly case insensitive but /sometimes/ case preserving - keep that in mind! (This does not confuse git neccessarily - but it can and does confuse the user of the git repo).
Finally, git is substantially slower on windows than it is on linux, although it is (in my limited experience) faster than the alternatives.
Now, regarding the path...
Unless I'm mistaken, you should be able to just ensure that the main git binary is in the path - and that binary should then take care of referencing the other git components... But I have not tested this.
The MSYS Git installer suggests option 2 if you intend on running git from a cygwin prompt. The cygwin environment ensures that git dependencies are in your PATH. If you choose this option but then invoke git from a windows command prompt, all of the unix-y command-line utilities that git relies upon will not be found. IIRC, git itself is partially implemented as bash scripts. I don't know which operations will fail, but I do not think that git will be usable this way.
I don't have a list of the system tools that option 3 overrides (the installer mentions find.exe) but this would only affect you if you are a batch-script ninja. At the command-line, find
will now refer to the unix utility of that name, not the exe that ships with windows. It doesn't harm windows itself in any way.
Just run with scissors and choose option 3 :-)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With