This is related to another question I asked recently.
When installing msysgit, the installer presents 3 options related to system path:
Never change
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
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
.
When you use the Windows GUI on windows, and you create your very first repository, do not type in the name ".git" for the repository directory. (Which it will then create, and then create another .git folder underneath it, when you finally think to look there) Browse to the folder with your sources in it, and -- just choose that folder! The repository directory ".get" will be created FOR you.
Then you see files in your unstaged changes, and by clicking on the little page icons next to the filenames, move them into the staged changes.
And definitely run with scissors and select option 3. No one uses kill, sort or find anymore from the command windows line.
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 :-)