views:

3040

answers:

5

This is related to another question I asked recently.

When installing msysgit, the installer presents 3 options related to system path:

  1. Never change windows environment. With this option, you have to use the "bash" shell to work with git.

  2. 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?

  3. 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?

+1  A: 

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.

Arafangion
AFAIK, Windows is always case preserving. When a name is all-caps Windows Explorer shows it as lowercase, but the file is kept as upper-case.
configurator
That is wrong, but it would be helpful if you found supporting articles. :)
Arafangion
+1  A: 

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 :-)

Gabe Moothart
This would affect non-batch-script-ninjas if they use any tool that comes with a batch scripts. I've used too many tools like this, which would probably fail.
configurator
+5  A: 

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 pages on their MSysGit wiki

VonC
+5  A: 

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.

Jonathan Lonowski
A: 

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.

hmm, this has nothing to do with msysgit on windows (as this applies to linux as well). I was asking about ways in which it might interfere with, or otherwise mess up, other windows system tools.
hasen j