msysgit / msysgit

msysGit has been superseded by Git for Windows 2.x

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.

msysgit's Issues

CACert.org certificates in curl-ca-bundle.crt

The root certificates of CACert.org (https://www.cacert.org/index.php?id=3) are missing in curl-ca-bundle.crt. Adding them should enable usage of CACert.org-certified certificates.

git for windows homepage points to huge download install

When you click on the google code link for msysgit on the home page it only displays the netinstall version of git which when you start it downloads like .5 gig of files. Says its for hacking. Is this the normal download size for a git install? I dont want to hack anything.

http://msysgit.github.com/

Git Bash shortcut causes side-effects for other program's icons

On Windows 8 x64, the shortcut target that Setup creates to Git Bash is as follows:

C:\Windows\SysWOW64\cmd.exe /c ""C:\Program Files (x86)\Git\bin\sh.exe" --login -i"

This shortcut is also set to have its icon point to git.ico.

Having a shortcut whose executable is cmd.exe and whose icon is git.ico as side-effects of making this icon appear in some other circumstances when cmd.exe runs. For example, doing Start without Debugging (Ctrl+F5) in Visual Studio 2012 internally uses cmd.exe to run MyProgram.exe & pause; such windows show up with git.ico.

If instead the Git Bash shortcut uses this target, other cmd.exe windows are not affected:

"C:\Program Files (x86)\Git\bin\sh.exe" --login -I

(Creating issue from mailing list discussion at https://groups.google.com/forum/#!topic/msysgit/raMI2zbKkq0)

msysgit.github.com uses "Git for Windows" logo as favicon

I think it would be more appropriate to use msysgit logo as favicon for the page. :-)

Recursive Submodule update fatal error

I am unable to use a recursive submodule using Git-1.7.11-preview20120710. This seems to be a reproducible case of issue #22 (which is now closed, I don't have permissions to reopen)

git clone https://github.com/racker/virgo.git
cd virgo
git submodule update --init --recursive

Gets this error:

This git repository and submodules works correctly on Linux or OSX.

new git icon has white background on x86 desktop

expected: git icon (git bash, gui, gtk) should have invisible background.
currently: git icon (on desktop) has which background

system: xp sp3 (x86)
msysgit: (git for windows) 1.7.11-preview20120704

also note:
git gui title bar icon is unreadable
gitk title bar icon is unchanged
on x64 (windows 7, haven't checked xp64) icon points to %PROGRAMFILES%\Git\etc\git.ico, but git is in Program Files (x86), not and echo %PROGRAMFILES% is Program Files (the x64 folder).

Win8, 64bit: git-cheetah shell extension

I have Windows 8 installed. When choosing "git-cheetah shell extension", it does not appear at the menu. The alternative baisc entry (via registry) work.

Installer: DirExistsWarning issue

After some recent changes, an ini file is created in the {app} directory to check if it's writable by the installer.
The problem is that DirExistsWarning is enabled (or Auto) so the first time Git is installed, the dir doesn't exist but because of that file being created the user sees the warning.

The ini file should either be created later or (the easy solution, but probably not the best) disable DirExistsWarning.

fatal: no man viewer handled the request

$ git help git
warning: failed to exec 'man': No such file or directory
fatal: no man viewer handled the request

Windows 7 SP1 x64

Unable to patch with GIT binary patches

Right now it seems msysgit does not support GIT binary patches?

It looks like this is because we are not using one of the later releases of patch.

We are using version 2.5 and it seems this feature was added in 2.5.6?

Could someone comment whether this should work in msysgit?

bash completion of branch for 'git pull origin <branch>' jumps to 'Enter passphrase for key ...:'

current: type git pull origin <letters> then hit tab, and Enter passphrase for key ...: is returned, on the same line, awaiting your .ssh passphrase. Also occurs for git fetch origin <letters>, but not for git push origin <letters>.

expected: If <letters> is the beginning of a branch then the branch should be auto-completed.

msysgit version: Git-1.7.11-preview20120710
git version: 1.7.11.msysgit.1
OS: windows xp sp3 (x86)

I would not say this is critical as bash completion is a bit of a luxury. I looked through .bash_completion only briefly, but if I have time I will take a more extended look ...

Windows, Pathname too long (>256 chars)

Using *current version of msysgit for Windows (Win7 64bit), there is a big issue when
having pathnames longer than 256 characters.

The problem occurs, if git have to handle files with such an long path name.
Than, there will be "internal errors" poping up: "File or path name too long".
After that, thing getting more and more worse.

---

I did some investigations.

It seems, that the underlying "old" cygwin has some influence.

My test setup is Windows7 64bit "Git version 1.7.8-preview20111206". (also current one)
I've created some source folders with a length of 260+ long path names.
"git add" shows the following error:
fatal: unable to stat 'Adobe InDesign CS6 Server SDK/tools/benchmark/BenchmarkChartsConsole/src/com/adobe/ids/benchmark/
samples/dce/source/suribachi/src/suribachi/api/vo/action/tools/benchmark/BenchmarkChartsConsole/src/BenchmarkChartsConso
le-app.xml': No such file or directory
Of course, this file exists but has a long path.

Additionally I've tested this command ing Git bash:
"find . | wc -L"
Pops up this error (and much more):
find: ./Adobe InDesign CS6 Server SDK/tools/benchmark/BenchmarkChartsConsole/src/com/adobe/ids/benchmark/samples/samplec
lient-java-soap/src/com/adobe/ids/samples/sampleclient-aspnet-soap/sampleclient-aspnet-vb-soap/Default.aspx.vb: File or
path name too long

Than I've checked the find command within cygwin (CYGWIN_NT-6.1-WOW64 momo 1.7.15(0.260/5/3) 2012-05-09 10:25 i686 Cygwin)
Again "find . | wc -L" ... no errors,
result : 299

My blind guess:
So maybe just linking git against a newer cygwin should work?

Any help is appreciated, to get GIT work with long path names.

Still hanging on git push on https on 1.7.11

I think I'm still having this issue: #23

I can pull just fine, but I can't push behind my corporate proxy. It just hangs, and I don't even get anything with GIT_CURL_VERBOSE. When I do a ls-remote to this same repo, I get this from curl_verbose:

< HTTP/1.1 200 Connection Established
< Proxy-Agent: Zscaler/3.6
<
* Proxy replied OK to CONNECT request
* successfully set certificate verify locations:
*   CAfile: c:\Program Files (x86)\git/bin/curl-ca-bundle.crt
  CApath: none
* Expire cleared
* SSL connection using RC4-SHA
* Server certificate:
*        subject: businessCategory=Private Organization; 1.3.6.1.4.1.311.60.2.1.3=US; 1.3.6.1.4.1.311.60.2.1.2=California; serialNumber=C3268102; C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=github.com
*        start date: 2011-05-27 00:00:00 GMT
*        expire date: 2013-07-29 12:00:00 GMT
*        subjectAltName: github.com matched
*        issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert High Assurance EV CA-1
*        SSL certificate verify ok.
> GET /polidore/ss-angular.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.7.11.msysgit.0
Host: github.com
Accept: */*
Pragma: no-cache

< HTTP/1.1 200 OK
< Server: nginx/1.0.13
< Date: Mon, 02 Jul 2012 13:35:01 GMT
< Content-Type: application/x-git-upload-pack-advertisement
< Transfer-Encoding: chunked
< Connection: keep-alive
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate

Can not CLONE using both RECURSIVE + BRANCH options

Ok, now i enter manually to C:\Program Files\Git\Git Bash

$ git clone --recursive -b 6.x-2.x [email protected]:project/counter
.git
Cloning into 'counter'...

fatal: The remote end hung up unexpectedly

Hmmm .. look like bug into Git-1.7.10-preview20120409

Strange behaviour in PATH with Cygwin

Discovered on Git For Windows (1.7.11). I have Cygwin installed and it is in my Path. When I append a new folder to my path, Git Bash will not find it unless it is suffixed with a semi-colon.

Cygwin, cmd.exe, and running Git/bin/sh.exe with no login, all find it.

• If I remove Cygwin from my path, Git Bash finds it (with or without the trailing semicolon)
• If I leave Cygwin in my path, I need to append a semi-colon for Git Bash to find it.

A quick hack is to alter the profile script and append a path separator:

if [ $MSYSTEM == MINGW32 ]; then
  export PATH=".:/usr/local/bin:/mingw/bin:/bin:$PATH:"
else
  export PATH=".:/usr/local/bin:/bin:/mingw/bin:$PATH:"
fi

Note that Git Bash shows the newly appended folder from env, but would not appear to use it.

Is this a general problem, or something to do with my own setup ?

Upgrade SSH

Msysgit is using OpenSSH 4.6p1 while the current version of Cygwin is at least 5.3p1.

Issues with the old one include:

• Performances (see http://stackoverflow.com/questions/783906/git-under-windows-msys-or-cygwin/9237853#9237853)
• Compatibility issue when used with other tools
• Possibly more

"git add" lower cases the first letter of the parent directory?

Noticed the following on git version 1.7.11.msysgit.1

Say you want to add a new file

/GTest/Foundation/newfile.txt

git add newfile.txt

git status
shows the new file as
../../gtest/Foundation/newfile.txt
(with lower case g!)

This is something much earlier versions wouldn't do and causes conflicts since two folders will exists when the commit is pushed to a git server - gtest for the new file and GTest for those using previous versions. The folder in Windows is indeed named GTest.

git.exe should honor the casing of the parent folder.

SFTP remote repos - adding sftp remote helper.

Trying to push to a sftp:// remote repo returns an error fatal: unable to find remote helper for 'sftp'. Is there a way one can add the sftp support?

Configure Remote Access with Users & Access Control Rules

I have just downloaded and installed it on Windows Server 2008. I want create new user with access to specific repository who will only be able to do this. Moreover, I didn't find any way for other users to access repository setup on Server? On what url will it be available. There isn't any settings either.

Please advise.

Upgrade perl

The old perl 5.8.8 is included in msysgit. But 5.16.1 is the current stable recommended release.

Feature request: Please enable the "large address aware" linker option.

Hi,

Would it be possible to link the msysgit binaries with the equivalent of the Visual Studio /LARGEADDRESSAWARE linker option? (http://msdn.microsoft.com/en-us/library/wz223b1z(v=vs.80).aspx)

I've seen the process run out of address space when doing a repack or gc on occasion, and I reckon an extra 2GB of address space (provided you're running a 64-bit OS) would help in such situations. Does the memory manager used by the 32-bit binaries support a 4GB address space?

Thanks!

Best regards,
Pierre le Riche

P.S. Thank you very much for a great product!

File name - ANSI to UTF-8

To the version 1.7.11-preview20120620 the file name encoded in ANSI. Now in UTF-8.

Git reads these files the different.

Upgrade base system files

MSysGit should be ship with updated versions for the base system commands like grep and other utilities to make new features of those tools available for use. Especially Grep is missing a near 5 (10?) years of updates.

no such variable "COMMONPROGRAMW6432"

add-shortcut.tcl line 84

Possible git-receive-pack.exe installation issue

Hi,

The installer (Git-1.7.10-preview20120409.exe) installs an executable file for libexec\git-core\git-receive-pack.exe on Windows XP, but under Vista and later the installed git-receive-pack.exe is a shortcut to git.exe instead.

The shortcut mechanism works fine under a local command prompt, but seems to cause a problem when attempting to push to the repository via a non-interactive ssh session, e.g. when using TortoiseGit:

The command:
git.exe push --progress "origin" master:master

Returns this error:
git: 'c:/myrepos/reponame.git' is not a git command. See 'git --help'.
fatal: The remote end hung up unexpectedly

It appears that under a non-interactice ssh session that the shortcut does not pass "receive-pack" as first parameter to git.exe, but the name of the repository instead.

As a workaround, the following can be run on the local computer to fix the issue for TortoiseGit:
git config --global remote.origin.receivepack "git receive-pack"

As mentioned earlier, this workaround is not required on Windows XP, since the installer installs an executable and not a shortcut to git.exe.

More on this issue here:
http://stackoverflow.com/questions/2550422/git-failed-at-pushing-to-remote-server-repository-path-is-not-a-git-comma

Is this an SSH issue, a TortoiseGit issue, or something that should be addressed in the installer?

Thanks!

Pierre

Improve "Git Bash Here"

For some time now I have noticed "Git Bash Here" has worked like this

1. Installer writes registry entries for right click folders.
2. Registry entries call VBS file
3. VBS file dynamically creates a Windows shortcut with the correct working directory
4. Shortcut is called.

Now I havent said anything against this until now because it was a better solution that even Cygwin is offering, by which I mean that Cygwin’s chere is calling bash.exe twice through a hack, where Msysgit method only invokes 1 instance of sh.exe.

I have noticed today, it appears that you can start Bash without using a VBS file. Instead of using

wscript "Git Bash.vbs" "%1"

You can simply do

cmd /c cd %v & start bin\sh.exe -l

Of course you will need to modify the command to include full path, etc, but you see the point. The registry changes to correct directory and invokes Bash at that directory. I have tested this on Cygwin but it should work here as well.

Relevant links

• .cygwin
• Git Bash.vbs
• install.iss

Prevent shadow copies being used instead of updated files

Issue

In reference to https://groups.google.com/forum/#!topic/msysgit/Tv1xccF6OlY

I finally found why I was getting an "ERROR: Your msys-1.0.dll is out-of-date!"

Details

Windows7 has a security feature where changes to the /c/Program Files* folder are shadowed. The feature is built to prevent virus infection between users on the same machine.

For instance, If you edit with a vi /etc/profile. the change is likely to be still there even if you reinstall git with the msys installer. The same applies to .dll and in fact any changes that may happen under program files

How to fix

It's actually very simple, but I will need direction to provide a fix. Or maybe someone else to do it on my behalf.

The installer needs to delete the following folder (matching the installation folder /c/Program Files (x86)/Git)

$HOME/AppData/Local/VirtualStore/Program Files (x86)/Git

and that's it !

New git.exe wrapper do not return correctly

Hello. Hope I report this correctly.

Just installed Git-1.7.11-preview20120704.exe and can see an issue with git.exe wrapper, where it returns 1, instead of 0.

From a new install on a windows xp machine without any git installation before.

Microsoft Windows XP [Version 5.1.2600](C) Copyright 1985-2001 Microsoft Corp.

Y:>echo %errorlevel%
0

Y:>git --version
git version 1.7.11.msysgit.1

Y:>echo %errorlevel%
1

Y:>

On a windows 7 64 bit, just upgraded to 1.7.11.1, and still have the old git.cmd wrapper.

Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\cst>echo %errorlevel%
0

C:\Users\cst>git.cmd --version
git version 1.7.11.msysgit.1

C:\Users\cst>echo %errorlevel%
0

C:\Users\cst>git.exe --version
git version 1.7.11.msysgit.1

C:\Users\cst>echo %errorlevel%
1

C:\Users\cst>

git.cmd eats ^, introducing incompatibility

git.cmd does "git.exe %@", which treats ^ in the argument as a special character. This processing breaks the command line interface compatibility with git.exe (or with git on Unix platforms.)

I'm a developer of Jenkins, a continuous integration server. At some point my program executes git rev-parse sometag^{commit} — if this finds git.exe (or other flavors of git, such as git from Cygwin), then this will work as expected. But if someone has git.cmd from msysgit in PATH before git.exe, then cmd.exe will end up executing git.exe rev-parse sometag{commit}, which obviously doesn't work.

If I change my git invocation to git rev-parse sometag^^{commit} then now it'll work with git.cmd, but it will not work when git.exe is found in PATH. And needless to say, this is incompatible with how I'd invoke git on Unix.

I consider this to be a bug on msysgit. It shouldn't let cmd.exe process its arguments.

Unfortunately I don't have enough Windows-fu to be able to send in a patch, so I'm just filing this as an issue instead.

See JENKINS-13007 where this is biting us.

Recursive submodule checkout error

Has this issue been resolved?

http://groups.google.com/group/msysgit/browse_thread/thread/01e774730740f3cb

It seems that

git clone --recursive [repo]

works fine,

but

git clone [repo]
git submodule update --init --recursive

does not work.

Gitk translation to portuguese (space change)

Inside gitk there's a checkbox which says:
Ignore space change

It was translated to portuguese (pt-br) as:
Ignorar mudanças de caixa

But that message in portuguese means:
Ignore case changes

that checkbox does not ignore case changes, but instead it ignore space changes, a better translation would be

Ignorar mudanças de espaço
or
Ignorar espaçamentos
or
Ignorar espaços

update 7zsd module

The problem with the current 7zsd module is that it's so old that it doesn't contain a proper manifest for Windows 7 (probably the same will happen on Windows 8) which results in Windows bugging you when you close the exe if the program has been installed properly.

I'd suggest to update 7zsd to the latest version, I personally still use "7zsd_150_2100" but at this time of writing "7zsd_150_2485" is available. Also updating to 7-zip v9.20 should be a good move.

Support for path lengths > 260

Hi,

as you know, Windows has a limitation of max. 260 characters for path names. Is there any plans to support git operations, even when reaching this limit, e.g. by leveraging the "?" notation (see http://msdn.microsoft.com/en-us/library/aa365247.aspx)?

Ben

git <-> svn broken in Git-1.7.11-preview20120620

svn integration is broken in Git-1.7.11-preview20120620, probably were not updated:
\lib\perl5\site_perl\Git.pm
\lib\perl5\site_perl\Git\

help viewer not working on 1.7.11

msysgit: 1.7.11-preview20120620
system: windows xp sp3 (x86), windows 7 (x64) and windows xp (x64)

expect: start git bash, type git help commit, commit help man page opens in browser or displays in bash
current: "warning: failed ot exec 'man': No such file or directory \ fatal: no man viewer handled the request

failure during installation

steps followed

1. system: Windows Vista Home Premium, Service Pack 2, AMD x64 Turion
2. installed msys, ran mingw-get update (mingw-get-inst-20120426)
3. downloaded msysGit-netinstall-1.7.11-preview20120620.exe. ran program

result:

• [new tag] v1.7.8-rc4 -> v1.7.8-rc4
• [new tag] v1.7.8.1 -> v1.7.8.1
• [new tag] v1.7.8.2 -> v1.7.8.2
• [new tag] v1.7.8.3 -> v1.7.8.3
• [new tag] v1.7.8.4 -> v1.7.8.4
• [new tag] v1.7.8.5 -> v1.7.8.5
• [new tag] v1.7.8.6 -> v1.7.8.6
• [new tag] v1.7.9 -> v1.7.9
• [new tag] v1.7.9-rc0 -> v1.7.9-rc0
• [new tag] v1.7.9-rc1 -> v1.7.9-rc1
• [new tag] v1.7.9-rc2 -> v1.7.9-rc2
• [new tag] v1.7.9.1 -> v1.7.9.1
• [new tag] v1.7.9.2 -> v1.7.9.2
• [new tag] v1.7.9.3 -> v1.7.9.3
• [new tag] v1.7.9.4 -> v1.7.9.4
• [new tag] v1.7.9.5 -> v1.7.9.5
• [new tag] v1.7.9.6 -> v1.7.9.6
• [new tag] v1.7.9.7 -> v1.7.9.7
  fatal: read error: Invalid argument
  • error: Couldn't update submodule git!
    INSTALLATION ABORTED

hit 'x' on window

---

Building and Installing Git

make: *** No rule to make target `install'. Stop.

---

Hello, dear Git developer.

This is a minimal MSYS environment to work on Git.

Your build failed... Please fix it, and give feedback on the Git list.

Welcome to msysGit

Run 'git help git' to display the help index.
Run 'git help ' to display help for specific commands.
Run '/share/msysGit/add-shortcut.tcl' to add a shortcut to msysGit.
sh.exe": /git/contrib/completion/git-completion.bash: No such file or directory
sh.exe": __git_ps1: command not found

me@mycomputer /git

msysGit-netinstall-1.7.11-preview20120620

git over HTTPS hangs if behind a proxy

msysgit 1.7.10 hangs when performing operations over https behind a proxy. http works fine. Downgrading to 1.7.9 also works.

The issue is detailed in these links:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627335
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671827

Looks like there are new releases of curl/libcurl that have this fixed. Can we get these incorporated into msysgit?

Thanks!

where is SVN::Core::auth_get_platform_specific_client_providers

I found this line in lib/Git/SVN/Ra.pm
SVN::Core::auth_get_platform_specific_client_providers(@A)
but I grep auth_get_platform_specific_client_providers * in the root of msysgit
I didn't find the definition of this function . Is is a bug?

Regression bug in Git-1.7.11-preview20120704.exe

Fix that addressed issue #36 broke GitExtensions and our internal automation tool. The new git.exe wrapper returns error code 1 on successful operations. Here is repro:

git init
echo Exit Code is %errorlevel%

When git is called from external programs, error code and stderr usually are analyzed to capture errors. Not zero error code and not empty stderr signal some kind of error. Wrapper should have the same behavior as the original git.exe and propagate all errors transparently.

git submodule add <path> doesn't handle backslashes

e.g.

> git submodule add http://github.com/ryppl/ryppl.git .dependencies\ryppl
fatal: Could not switch to '.git/modules/.dependencies\': No such file or directory
Clone of 'http://github.com/ryppl/ryppl.git' into submodule path '.dependencies\ryppl' failed

If I use forward slashes, it works.

mingw-w64-*zip download issue

I first thought it was my firewall, but it's not: Mingw-w64-*.zip is not being downloaded properly.

Started from a fresh net install, then run /share/WinGit/release.sh -f 1.7.10
.. the process fails because the zip mingw-w64-*zip is only a few bytes long.

Had to run /src/mingw-w64/release-easy.sh to get the package installed properly.

Trying to identify how can this be but though I would share the problems for others to pick up.

Sincerely,

Bash completion is occasionally slow

Hi,

I'm using msysgit for some time now in an industrial environment and it works quite well. It's just very annoying, that very often the tab autocompletion just "hangs" (the whole bash, but memory, processor load, harddisk, etc. seems normal) for approx. 30 seconds. After waiting that time it works like a charm. Then some hours later it happens again.

Some days ago, I setup a .bash_profile in my $HOME path and it seems to work a little better. But still it happens.

I searched the web and found some hints and people mentioning that, but no real solution for that.

If it helps: I'm using win xp sp3; It also affects win7 machines as well; msysgit versions are 1.7.8 > 1.7.10

Fails with Exception: STATUS_ACCESS_VIOLATION

After upgrading from Git-1.6.5.1-preview20091022 to Git-1.7.10-preview20120409 my git has stoped working. For instance, when I try to open bash I get the following bash.exe.stackdump:

MSYS-1.0.12 Build:2011-07-20 17:52
Exception: STATUS_ACCESS_VIOLATION at eip=6801364A
eax=00005009 ebx=00005009 ecx=7C80EEF7 edx=00000000 esi=0022FE34 edi=0022FA34
ebp=0022F8A4 esp=0022F88C program=C:\Program Files\Git\bin\bash.exe
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022F8A4  6801364A  (00005009, 00000000, 00110000, 00000000)
  12193 [main] bash 4092 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
  12848 [main] bash 4092 handle_exceptions: Error while dumping state (probably corrupted stack)

Reverting back to Git-1.6.5.1-preview20091022 restores normal functioning.

I'm on Win XP Pro + SP3.

vim looks awful when ssh'ed, but only on one machine

Hey there-

Sorry to have to file this as a bug -- I'm pretty sure it's something weird in my config -- but I can't find anything on it, and it's driving me nuts, so I need to get some kind of an answer.

I have two very similar Windows 7 environments that I hack on. On one of them, when I'm sshed into a work server, using msysgit and Console2, vim looks and behaves as it should -- it colour-codes and scrolls properly. On the other machine, it not only doesn't colour code, but it doesn't clear the page properly when it scrolls upward, which is a disaster. I've uploaded a screenshot here: http://imgur.com/etm0h

I can't for the life of me figure out what's different between these two installs, but I know this shouldn't be happening.

possible to provide a package to install with mingw-get?

just as the title, it would be great if it's possible to install git via mingw-get install, so that I can have both git for windows and all the goodies in msys.

Last netinstaller fails to checkout branch devel

the net installer should be rebuilt to checkout branch master now that devel has been renamed.

Under win32, msysgit git svn always corrupted the authorfile path.

[svn-remote "svn"]
url = https://192.168.1.12/svn/code/common/catos/trunk
fetch = :refs/remotes/git-svn
[svn]
authorsfile = D:/CI/wsn/catos/authors-file.txt

And msysgit din't write the svn-remote config to the .git/config files,
but write to %HOME%.gitconfig

Duplicate files under \libexec\git-core\ (in portable version)

All of these files are exactly the same! You never heard of command line :)

Single one being 1.3MB and all of them 140MB. What a waste of space (note: it was proven wrong that this is a waste of space).

git-add.exe
git-annotate.exe
git-apply.exe
git-archive.exe
git-bisect--helper.exe
git-blame.exe
git-branch.exe
git-bundle.exe
git-cat-file.exe
git-check-attr.exe
git-check-ref-format.exe
git-checkout-index.exe
git-checkout.exe
git-cherry-pick.exe
git-cherry.exe
git-clean.exe
git-clone.exe
git-column.exe
git-commit-tree.exe
git-commit.exe
git-config.exe
git-count-objects.exe
git-describe.exe
git-diff-files.exe
git-diff-index.exe
git-diff-tree.exe
git-diff.exe
git-fast-export.exe
git-fetch-pack.exe
git-fetch.exe
git-fmt-merge-msg.exe
git-for-each-ref.exe
git-format-patch.exe
git-fsck-objects.exe
git-fsck.exe
git-gc.exe
git-get-tar-commit-id.exe
git-grep.exe
git-hash-object.exe
git-help.exe
git-index-pack.exe
git-init-db.exe
git-init.exe
git-log.exe
git-ls-files.exe
git-ls-remote.exe
git-ls-tree.exe
git-mailinfo.exe
git-mailsplit.exe
git-merge-base.exe
git-merge-file.exe
git-merge-index.exe
git-merge-ours.exe
git-merge-recursive.exe
git-merge-subtree.exe
git-merge-tree.exe
git-merge.exe
git-mktag.exe
git-mktree.exe
git-mv.exe
git-name-rev.exe
git-notes.exe
git-pack-objects.exe
git-pack-redundant.exe
git-pack-refs.exe
git-patch-id.exe
git-peek-remote.exe
git-prune-packed.exe
git-prune.exe
git-push.exe
git-read-tree.exe
git-receive-pack.exe
git-reflog.exe
git-remote-ext.exe
git-remote-fd.exe
git-remote.exe
git-replace.exe
git-repo-config.exe
git-rerere.exe
git-reset.exe
git-rev-list.exe
git-rev-parse.exe
git-revert.exe
git-rm.exe
git-send-pack.exe
git-shortlog.exe
git-show-branch.exe
git-show-ref.exe
git-show.exe
git-stage.exe
git-status.exe
git-stripspace.exe
git-symbolic-ref.exe
git-tag.exe
git-tar-tree.exe
git-unpack-file.exe
git-unpack-objects.exe
git-update-index.exe
git-update-ref.exe
git-update-server-info.exe
git-upload-archive.exe
git-var.exe
git-verify-pack.exe
git-verify-tag.exe
git-whatchanged.exe
git-write-tree.exe
git.exe

4-byte UTF-8 character not supported?

When having tried to commit with a commit message involving a four-byte UTF-8 character, namely non-BMP character, U+2123D, using Git GUI, the warning "commit message does not conform to UTF-8." came out.
With three-byte UTF-8 character, U+5721, no problem.

And filenames involving four-byte UTF-8 character shall be corrupted on Git GUI and gitk.
For example, when the filename is including U+2123D, it shall be displayed as "�" on these tools.

Files with spaces in name and TortoiseMerge

What steps will reproduce the problem?

1. Add file with space in the name ("New file") and make merge conflict on it
2. perform "git mergetool" in command-line

What is the expected output? What do you see instead?
Expect merge tool to load file versions for merging
But it gives an error
"The diffing engine aborted because of an error:
Can't open file '.\New'"

What version of TortoiseGit and msysgit are you using? On
what operating system?
TortoiseGit-2012-08-04-248f1de-32bit, Git-1.7.11-preview20120710
WinXP SP3

Tortoisemerge's commandline is:
d:\Coding\Tools\TortoiseGIT\bin\tortoisemerge.exe "-base:./New File.BASE.2736" "-mine:./New File.LOCAL.2736" "-theirs:./New File.REMOTE.2736" "-merged:New File"

while it should be ...-base:"./New File.BASE.2736" and so on.

Firstly I posted this issue on TGit page here: http://code.google.com/p/tortoisegit/issues/detail?id=1324 but guys redirected me here.