msysgit / git-cheetah

A concise and small shell extension for Git

Please note!

Git for Windows 1.x was retired on August 18th, 2015, superseded by Git for Windows 2.x. The development environment of Git for Windows 2.x is no longer maintained in a monolithic Git repository but rather as the Git SDK, a friendly fork of MSys2 pre-configured to ease the development of Git for Windows.

Build environment for Git for Windows 1.x

This is the build environment -- also known as msysGit -- for Git for Windows.

The easiest way is to install it via the net installer. This installer will clone our two repositories, including all the necessary components to build Git for Windows, and perform an initial build.

The build environment

msysGit brings a few components that are required to build Git:

• Bash, a Unix-type command-line shell. Quite a few components of Git itself are still shell scripts. Therefore, Bash is required to execute Git commands (see the output of cd /git && git ls-files \*.sh for a full list).
• the GNU C Compiler. Since we try to rely only on free software (apart from the Operating System, of course), we think it makes more sense to rely on GCC than on Visual Studio express. Also, it makes the maintenance burden lighter, as upstream Git also targets mainly GCC.
• GNU Make.
• Perl. Still required for a couple of Git components (see the output of cd /git && git ls-files \*.perl), most notably git svn.
• Tcl/Tk, a scripting language making it easy to implement cross-platform graphical user interfaces. We need this for gitk and git gui.
• cURL, a library implementing HTTP and FTP transport.
• many more libraries.
• some Unix programs required by the shell scripts in Git.

The relationship between msysGit and Git for Windows

Git for Windows is the software package that installs a minimal environment to run Git on Windows. It comes with a Bash (a Unix-type shell), with a Perl interpreter and with the Git executable and its dependencies.

On the other hand, msysGit is the software package installing the build environment that can build Git for Windows. The easiest way is to install it via the net installer.

The difference between MSys and MinGW

The MinGW project's goal is to provide a way to compile native Windows binaries with no POSIX layer using the GNU C Compiler.

However, at least the Bash needs a POSIX layer (most notably due to the absence of the fork() call on Windows). Therefore, MSys (the minimal system) is thrown in, offering the minimal system necessary to offer Bash (and Perl) functionality on Windows.

Consequently, MSys ships with a POSIX layer (based on an old version of Cygwin) that is only used by the Bash and Perl, but not by anything compiled within that environment.

Further information

For more information and documentation, please have a look and enhance our Wiki.

For code contributions and discussions, please see our mailing list.

git-cheetah's Issues

Duplicated menu items in Folder pane

On Vista duplicated Git menu entries are added when you right-click a folder in the Folders pane

This is because the Shell calls the handler for the Directory\Background progid first (with a folder pidl), then calls it again for the other entries with a data object. So the trick is to check if the Git menu has already been written.

One way you can do this is by using InsertMenuItem on all menu entries and adding a unique identifier (your module handle, for example) to the dwItemData member of the item structure.

    MENUITEMINFO mii = { sizeof(mii) };
    mii.cbSize = sizeof(MENUITEMINFO);
    mii.fMask = MIIM_STRING |  MIIM_ID | MIIM_DATA; // add MIIM_SUBMENU for a sub menu
    mii.dwItemData = (ULONG_PTR) hInstance;
    ...
    InsertMenuItem(hMenu, menuIndex, TRUE, &mii)

Then in the QueryContextMenu function you can check if any menu item has this value and act accordingly:

    MENUITEMINFO mii = { sizeof(mii) };
    mii.cbSize = sizeof(MENUITEMINFO);
    mii.fMask = MIIM_DATA;

    // get the number of existing menu entries
    int count = GetMenuItemCount(hMenu);

    for (int i = 0; i < count; ++i)
    {
        // get the item data
        GetMenuItemInfo(hMenu, i, TRUE, &mii);

        if (mii.dwItemData == (ULONG_PTR) hInstance)
        {
             // menu already written   
            return S_OK;
        }
    }

    // menu not written
    ...

I had the same problem in an extension I was working on, and solved it with this solution.

fail - always read stdout and stderr from forked commands

This PR #11 fails and hangs Far Manager when a Git menu command is clicked. Tested on Vista (x86).

So the problem must be with the pipes/redirected output since it works pre PR, albeit reporting spurious error messages. Maybe it is waiting on a duplicated handle that should have been closed? Perhaps it combines stdout and stderr.

Incidentally, this will not actually compile in Visual Studio because the *debug variable is not declared at the beginning of the exec_program_v function which MSVC requires for .c files.

Suggestion: respect default terminal emulator

Users using ConEmu can configure it to be the system's default terminal emulator. I think it would be a good idea for the "Git Bash" Cheetah option to respect this choice.

git_shell_ext64.dll makes Far Manager run git before running batch files

Far Manager executes the following command prior to running cmd/bat files when git_shell_ext64.dll is registered: git rev-parse --show-prefix.

Git Cheetah causes explorer to crash when ".git/packed-refs" file is long enough

win7, git bash 1.9.5 (was happening for many weeks for me at least since 1.9.4)

I've started noticing that one of my repos is causing crashes / unresponsiveness / extremely long processing time (~40seconds) in windows explorer (Windows 7) when I right click the folder, or inside the folder (on some file or blank space).

This was happening only for a certain git repo and not the others.

I investigated and it seems the issue is the contents of certain files in .git folder.

Here's a script with a minimum working example in Windows 7 (tested on two machines):

#!/bin/bash
mkdir -p /d/xkiller/.git
cd /d/xkiller/.git
mkdir refs
mkdir objects
echo "ref: refs/heads/master" > HEAD
echo "# pack-refs with: peeled fully-peeled" >> packed-refs
node -e 'for(var i=0;i<360; i++) console.log("2aa83bb279c1f10d11fca7ee46e52869b3c4ee67 refs/heads/branch" + i) ;' >> packed-refs

(I was lazy and used nodejs to create packed-refs file)

• run the script to create D:/xkiller folder.
• then, open D: in windows explorer
• right click xkiller. It should hang your explorer window for 40+ seconds

It seem the issue at least partially is the length of packed-refs file, but I'm not sure if this is the only one (when I decrease file to be <250 lines the problem - in this particular scenario at least - goes away). It's pretty hard and time consuming to black-box-debug it :)

Can you please check if you can reproduce the issue?

git clone does not set tracking branch

I started by "git gui" selected git clone, and the resulting master branch was not connected to the remote origin, so that "git pull" failed there.

When I start by "git clone", I can immediately proceed with "git pull"

The difference can be checked in .git/config, in section branch.master.

Put all Msysgit's right-click context menu options in a sub-menu in Windows Exporer?

Is it possible (if not, please make it a feature-request) to put all Msysgit's right-click menu options in a sub-menu?

All of the options makes my menu enormous

Context menu modifications

Some git settings for the following would be nice. Regarding the discussion in #20, the settings don't need to be located in %appdata%, you can just as easily store them in a c:\program files (x86)\Git\config.ini or some such, or in git config settings in $HOME/.gitconfig, or in a registry entry (there should be some way to abstract between gconf and the registry...)

• Only show git items when the repo already exists; if .git doesn't exist, don't show anything.
• Show options for both powershell and git bash
• #20
• Probably far more windows-specific, it would be nice to have an overlays a la dropbox/skydrive/etc to show the status of files in a git repo (Icon Overlay Handler) or some other form of identifying the status of a file in explorer without first opening git. Even just setting the file metadata that's shown in the details/preview pane would be useful.

I started to check out whether or not the patch linked in #20 still works, however I am unable to install msysgit. One would think this is related to the fact that the installer places sh.exe in c:\msysgit\install_tmp, but copying the contents of c:\msysgit\install_tmp to c:\msysgit and rerunning the netinstall doesn't help. The netinstall is the "easiest" way to install msysgit, implying there's a less easy way, but I have no idea what the less easy way is, as it's not mentioned anywhere. Git for Windows SDK works fine, I just have to get around to trying it.

WM_SETTINGCHANGE not reflected

When the WM_SETTINGCHANGE message is received by windows shell (explorer), then the environment variables get updated.

It looks like that starting a git-bash via the explorer context-menu does not reflect these changes even though explorer itself already did reflect these changes.

Start a bash via WIN+R -> bash has reflected the changes for example.

Some example code is probably here: http://www.ghisler.ch/board/viewtopic.php?t=16292

configurabe context menu?

Hi, I'd like to adjust the content of the menu, removing unused item, e.g. "Add all files".
Is that possible without rebuilding git cheetah?
Stepan