Upstream mgwport is dead, last update from Friday, November 11 2011, I've tried to email the author no answer.

For the deterministic build changes I need to therefore create a new package mingw32-mgwport.

Do we want to have mgwport in git-for-windows org or should I keep it in t-b? For me both is okay.

Ported from msysgit#336:

I downloaded the git-sdk-64-installer-preview.7z.exe installer from https://github.com/git-for-windows/build-extra/releases/tag/net-installer-preview-1, decompressed its content to a directory, and then ran the setup-git-sdk.bat script.

The script fails immediately with the following output:

:: Synchronizing package databases...
 git-for-windows                                                                                  0.0   B  0.00B/s 00:00 [------------------------------------------------------------------------]   0%
 git-for-windows                                                                               1392.0   B  1359K/s 00:00 [########################################################################] 100%

error: failed retrieving file 'mingw32.db' from downloads.sourceforge.net : Connection timed out after 10000 milliseconds
error: failed to update mingw32 (download library error)
error: failed retrieving file 'mingw64.db' from downloads.sourceforge.net : Connection timed out after 10000 milliseconds
error: failed to update mingw64 (download library error)
error: failed retrieving file 'msys.db' from downloads.sourceforge.net : Connection timed out after 10000 milliseconds
error: failed to update msys (download library error)
error: failed to prepare transaction (could not find database)
warning: database file for 'mingw32' does not exist
warning: database file for 'mingw64' does not exist
warning: database file for 'msys' does not exist
error: target not found: pacman
warning: database file for 'mingw32' does not exist
warning: database file for 'mingw64' does not exist
warning: database file for 'msys' does not exist
:: There is 1 member in group base:
:: Repository git-for-windows
   1) msys2-runtime

Enter a selection (default=all):
error: target not found: python
error: target not found: less
error: target not found: openssh
error: target not found: patch
error: target not found: make
error: target not found: tar
error: target not found: diffutils
error: target not found: ca-certificates
error: target not found: perl-Error
error: target not found: perl
error: target not found: perl-Authen-SASL
error: target not found: perl-libwww
error: target not found: perl-MIME-tools
error: target not found: perl-Net-SMTP-SSL
error: target not found: perl-TermReadKey
error: target not found: mintty
error: target not found: mingw-w64-x86_64-toolchain
error: target not found: mingw-w64-x86_64-curl
error: target not found: mingw-w64-x86_64-expat
error: target not found: mingw-w64-x86_64-openssl
error: target not found: mingw-w64-x86_64-tcl
error: target not found: mingw-w64-x86_64-pcre
'mintty' is not recognized as an internal or external command,
operable program or batch file.

After retrying about a dozen times to rule out problems with SourceForge (as suggested by dscho) I switched the computer from the corporate network to the hotspot created by my mobile phone the script succeeded on the first try.

It seems the setup-git-sdk.bat script doesn't support proxies, as our corporate network doesn't have direct internet access — everything must pass through an HTTP proxy — while the mobile phone hotspot has.

With the msysGit-based Git for Windows, we benefitted from a bunch of patches to the MSys1 runtime, designed to speed up the initialization in the common case – when the Bash was started from within Git:

• https://github.com/msysgit/msysgit/blob/msys/src/rt/patches/0008-Do-not-start-the-fstab-observer-thread.patch
• https://github.com/msysgit/msysgit/blob/msys/src/rt/patches/0009-spawning-of-processes-combine-for-loops-and-resolve-.patch
• https://github.com/msysgit/msysgit/blob/msys/src/rt/patches/0011-msys.dll-Don-t-pull-user32.dll-friends-just-to-detec.patch
• https://github.com/msysgit/msysgit/blob/msys/src/rt/patches/0012-bash-Don-t-load-user32.dll-for-every-shell-process.patch

We need to figure out how/if we can forward port those patches, to bring back a little speed to Git for Windows even after the switch to MSys2.

If I run C:\Program Files\Git\mingw64\bin\git.exe instead of C:\Program Files\Git\cmd\git.exe outside bash, git commands written in shell script will fail.
e.g. git submodule, git rebase

fatal: 'submodule' appears to be a git command, but we were not able to execute it. Maybe git-submodule is broken?

I got some errors from the mingw-get stage of the SDK installation, but I can't easily report them because the window with the output insists on disappearing after everything is done.

(At least one of them is a 404 trying to download one of the packages.)

While testing on my little XP netbook I noticed that the echo $PATH has moved relative to the old MsysGit, so that my personal little BringUptodate script wasn't found. This is with the install from issue #42.

Philip@PhilipOakley MINGW32 ~
$ !Br
BringGitUptodate.sh
bash: BringGitUptodate.sh: command not found`

i.e. (new)

Philip@PhilipOakley MINGW32 ~
$ echo $PATH
/mingw32/bin:/usr/local/bin:/usr/bin:/bin:/d/Program Files/Windows Resource Kits/Tools:/c/Tcl/bin:[...]

v.s. (old)

Philip@PHILIPOAKLEY ~
$ echo $PATH
 /c/Documents and Settings/Philip/bin:.:/usr/local/bin:/mingw/bin:/bin:/d/Program Files/Windows Resource Kits/Tools/:/c/Tcl/bin:[...]

I haven't done any looking yet....

As of this morning, there were four repositories in the git-for-windows org that leave room for confusion with the current push for an MSys2-based Git for Windows:

• mgwport
• pacman-repository
• sdk
• sdk-packages

I already moved the pacman-repository repository into my personal GitHub space because its functionality is superseded by our Pacman repository on Bintray.

We should move the other three packages out of the way, too, lest some developer thinks that we are still basing Git for Windows 2.x on MSys 1.x.

C:\Users\luoyonggang>git
usage: git [--version] [--help] [-C ] [-c name=value]
[--exec-path[=]] [--html-path] [--man-path] [--info-path]
[-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
[--git-dir=] [--work-tree=] [--namespace=]
[]

×ÓõÄ git ÃüÁîÓУº
add Ìí¼ÓÎļþÄÚÈÝÖÁË÷Òý
bisect ͨ¹ý¶þ·ֲéÕҶ¨λÒýÈë bug µıä¸ü
branch Áгö¡¢´´½¨»òɾ³ý·Ö֧
checkout ¼ì³öһ¸ö·Ö֧»ò·¾¶µ½¹¤×÷Çø
clone ¿Ë¡һ¸ö°汾¿⵽һ¸öÐÂĿ¼
commit ¼Ç¼±ä¸üµ½°汾¿â
diff ÏÔʾÌύ֮¼䡢Ìύº͹¤×÷Çø֮¼äµȵIJîÒì
fetch ´ÓÁíÍâһ¸ö°汾¿âÏÂÔضÔÏóºÍÒýÓÃ
grep Êä³öºÍģʽƥÅäµÄÐÐ
init ´´½¨һ¸ö¿յÄ Git °汾¿â»òÖØгõʼ»¯һ¸öÒѴæÔڵİ汾¿â
log ÏÔʾÌύÈÕ־
merge ºϲ¢Á½¸ö»ò¸ü¶࿪·¢Àúʷ
mv Òƶ¯»òÖØÃüÃûһ¸öÎļþ¡¢Ŀ¼»ò·ûºÅÁ´½Ó
pull »ñȡ²¢ÕûºÏÁíÍâµİ汾¿â»òһ¸ö±¾µطÖ֧
push ¸üÐÂԶ³ÌÒýÓúÍÏà¹صĶÔÏó
rebase ±¾µØÌύתÒÆÖÁ¸üкóµÄÉÏÓηÖ֧ÖÐ
reset ÖØÖõ±ǰHEADµ½ָ¶¨״̬
rm ´ӹ¤×÷ÇøºÍË÷ÒýÖÐɾ³ýÎļþ
show ÏÔʾ¸÷ÖÖÀàÐ͵ĶÔÏó
status ÏÔʾ¹¤×÷Çø״̬
tag ´´½¨¡¢Áгö¡¢ɾ³ý»òУÑéһ¸öGPGǩÃûµÄ tag ¶ÔÏó

ÃüÁî 'git help -a' ºÍ 'git help -g' ÏÔʾ¿ÉÓõÄ×ÓÃüÁîºÍһЩ¸ÅÄî°ïÖú¡£
²鿴 'git help <ÃüÁî>' »ò 'git help <¸ÅÄî>' ÒԻñȡ¸ø¶¨×ÓÃüÁî»ò¸ÅÄîµÄ
°ïÖú¡£

Warning: Your console font probably doesn't support Unicode. If you experience strange characters in the output, consider switching to a TrueType font
such as Consolas!

C:\Users\luoyonggang>

When the $HOME directory is a git repository, Right click popup menu in Windows Explorer at the target directory; then click Git Bash Here, the git bash won't locate to the
target(current) git repository, but at the $HOME git respository.

Most likely, a lot of https://github.com/msysgit/msysgit/tree/master/share/WinGit can be scavenged to make this happen.

When using git to do ssh pull, it's cause the following error:

C:\Users\lygstate>git pull
error: cannot spawn ssh: No such file or directory
fatal: unable to fork

I am using the 64bit version of Git, maybe the result will differ in 32bit version.

The cmd\start-ssh-agent.cmd scripts are calling to ssh-agent.exe

When installing SDK 0.4, /packages/.git/hooks/ does not contain the pre-commit hook.

Edit: As stated below, I had Git installed in C:\Program Files (x86)\Git (the default recommended by the installer) which seems to have caused this issue. git rebase -m was the first thing I noticed.

Repro:

kedavid@KEDAVID-DEV [D:\work\git1] [feature]
> git lg
* 5c2d42d - (HEAD, master, feature) second commit commit (44 seconds ago) <Kevin David>
* 1a5b550 - first commit (52 seconds ago) <Kevin David>

kedavid@KEDAVID-DEV [D:\work\git1] [feature]
> git checkout master
Switched to branch 'master'

kedavid@KEDAVID-DEV [D:\work\git1] [master]
> git checkout -B feature 1a5b550
Switched to and reset branch 'feature'

kedavid@KEDAVID-DEV [D:\work\git1] [feature]
> testcommit feature commit
[feature 8128af2] feature commit commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 feature commit

kedavid@KEDAVID-DEV [D:\work\git1] [feature]
> git rebase -m master
First, rewinding head to replay your work on top of it...
git: 'Files' is not a git command. See 'git --help'.

Did you mean this?
        ls-files

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

testcommit creates a dummy commit and echos the arguments into a file with the same name (e.g. echo "feature commit" >> "feature commit"), so no magic there.

Running the developer's preview release.

We need to include the documentation in the mingw-w64-git packages, too.

Now that Git lives in /mingw32/ or /mingw64/, respectively, it looks into the wrong spot for the system-wide Git configuration.

I installed git v2.3.5 using net-installer:
https://github.com/git-for-windows/build-extra/releases/tag/net-installer-1.0.0-rc-1

• Started git-gui.exe
• started from menu Repository/Git Bash
• display git version:

user@PC MINGW64 /w/Dev/test
$ git --version
Segmentation fault

user@PC MINGW64 /w/Dev/test
$ git --version
Segmentation fault

user@PC MINGW64 /w/Dev/test
$ git --version
git version 2.3.5.windows.2.1.g9a5c96c

user@PC MINGW64 /w/Dev/test
$ git --version
Segmentation fault

It seems, that in MINGW64 bash sometimes it is executed fine, sometimes gives error:
Segmentation fault

I debugged it down, that 2 MINGW64 bash.exe was running in the memory.
When I closed the second one, all went fine, no seg fault.
But only if I executed one at a time.

It seems, that if I execute
git --version
multiple times quickly, then the
Segmentation fault
error happens sometimes.

It seems it might be something spawning problem.

This bug should be fixed.

A really nice feature of the pacman mirrorlists is that you can specify multiple locations for package indexes and all of them will be used.

That means that we actually do not have to override anything in /etc/pacman.conf because we can just piggy-back our Bintray repositories via the pacman-mirrors package that provides the mirrorlist.* files.

All we have to do is to make sure that the package index is actually not called git-for-windows.db.tar.xz, but mingw32.db.tar.xz, mingw64.db.tar.xz and msys2.db.tar.xz, respectively.

There are a bunch of really useful files shipped with Git for Windows, such as a sensible default gitconfig, a vimrc, etc. To make it easy to bundle them into a Portable Application/installer, we should make these files available as a package.

To make things even nicer for users – who might want to update their packages every once in a while – we could write out default versions of the files in a post_install/post_upgrade script only if the user does not have these files yet, but leave the (possibly modified) existing files alone.

@dscho - I've just done a fresh net install of the latest installer/builder, so here is the reports for what happens on XP. This is a courtesy note.

1. a couple of 'Permission denied' messages.
2. Loads of compile warnings, mainly of 'unknown conversion type character 'l' in format'
3. git status felt to take a long time.
4. git gui reports 'Git directory not found' (so this one feels like a Fail)

So generally a success, with #4# as a small problem.

Downloaded:
https://github.com/git-for-windows/git/releases/download/v2.3.4.windows.2/git-sdk-32-installer-dev

-preview.7z.exe
and ran - got to / past

(158/158) installing mingw-w64-i686-winstoreco... [######################] 100%

"Auto-rebasing .dll files"
mkdir: cannot change permissions of '/dev/shm': Permission denied
mkdir: cannot change permissions of '/dev/mqueue': Permission denied
'C:\WINDOWS\system32\drivers\etc\hosts' -> '/etc/hosts'
'C:\WINDOWS\system32\drivers\etc\protocol' -> '/etc/protocols'
'C:\WINDOWS\system32\drivers\etc\services' -> '/etc/services'
'C:\WINDOWS\system32\drivers\etc\networks' -> '/etc/networks'

Those permission denieds are on C:\git-sdk-32\dev which is set at 'read only'

Mintty came up, clone and compiled, with lots of warnings, generally of the sort
pack-check.c: In function 'verify_packfile':
pack-check.c:114:5: warning: unknown conversion type character 'l' in format [-W format=]
err = error("index CRC mismatch for object %s "
^
pack-check.c:114:5: warning: too many arguments for format [-Wformat-extra-args]
pack-check.c:121:4: warning: unknown conversion type character 'l' in format [-W format=]
err = error("cannot unpack %s from %s at offset %"PRIuMAX"",
^
pack-check.c:121:4: warning: too many arguments for format [-Wformat-extra-args]
[...]

Feeling of slowness... this is the second run.
Philip@PhilipOakley MINGW32 /c/msysgit195 (master)
$ git status
[...]
real 0m2.625s
user 0m0.015s
sys 0m0.109s
(this has git as a sub-module, but I'n not usually here and so it's maybe 'normal')

When trying to do a rebase with 2.3.5 i got:
git rebase --onto origin/ba 0b7200c
First, rewinding head to replay your work on top of it...
Applying: blah blah
fatal: unrecognized input
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 Moved heat index field to shared abstract class for import/export and
The copy of the patch that failed is found in:
C:/eclipse/git/irisba/.git/rebase-apply/patch

and I switched back to 1.8.1 and the rebase happened without any error or warning.

Looking at the patch file, it looks like it contains a lot of non printable characters. Please advise if there is anything I should be looking for.

Thanks
Alain

:: Synchronizing package databases...
 git-for-windows                                                                                  0.0   B  0.00B/s 00:00 [------------------------------------------------------------------------]   0%
 git-for-windows                                                                               1872.0   B   914K/s 00:00 [########################################################################] 100%

error: could not open file /var/lib/pacman/sync/1cb4ed32f5db94fc7c0f9ffa6b315f92fe2d50e3?response-content-disposition=attachment%3Bfilename%3D%22git-for-windows.db%22&Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZX
NvdXJjZSI6Imh0dHAqOi8vZDI5dnprNG93MDd3aTcuY2xvdWRmcm9udC5uZXQvMWNiNGVkMzJmNWRiOTRmYzdjMGY5ZmZhNmIzMTVmOTJmZTJkNTBlMz9yZXNwb25zZS1jb250ZW50LWRpc3Bvc2l0aW9uPWF0dGFjaG1lbnQlM0JmaWxlbmFtZSUzRCUyMmdpdC1mb3
Itd2luZG93cy5kYiUyMiIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTQyODQxOTE5NX0sIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIwLjAuMC4wLzAifX19XX0_&Signature=Dnkpi2dSSS5ZZYf-bQA143~aYDAPFrU
UrNnuWX7qCam72CCwfL2VT86JzQA8F8GaLtGz5pv-mvsS~8lV0UFjEqBHfSEiW-~vEwP9YcuKCtx5OmdYP9g0H5P4Qc5XXYdZuWP8rY2xCYwe2v3aUrpS0Nk9eRKbYXf0f9rc1YQj6MzqW4ab5T1yUEJbDWXJiNpBEHPElGD-McTtufFSU~3y5czbNJOg3mK8v6wZFTf
Iz2WM-anWrcikR0~IsWmg~aEsznMDKZ9XukCkKoa-d-SHWZZHljuFQPjQFK~dSe09JTV1zssZWPN~DmrYZCCGgnsOcFuUKkw3ls06n4EPceIvgA__&Key-Pair-Id=APKAIQIOJCQ5764M5VTQ.sig.part: File name too long
 mingw32                                                                                          0.0   B  0.00B/s 00:00 [------------------------------------------------------------------------]   0%
 mingw32                                                                                         21.6 KiB  13.2K/s 00:15 [######------------------------------------------------------------------]   9%
 mingw32                                                                                         53.6 KiB  38.2K/s 00:04 [################--------------------------------------------------------]  23%
 mingw32                                                                                        101.6 KiB  66.5K/s 00:01 [##############################------------------------------------------]  43%
 mingw32                                                                                        133.6 KiB  97.1K/s 00:01 

It's seems git-mirror doesn't compat with pacman

Distributions of Git built with msysgit include an /etc/inputrc file that, among other things, makes command-line completion case-insensitive, which makes sense for a Windows application as that's how the rest of the system behaves. The developers' preview build made with the Git for Windows SDK does not include such a file. The resultant behavior changes are likely to confuse users who upgrade or are new to Git and/or Bash. I recommend bring lines 1-25 of msysgit's inputrc file into the Git for Windows SDK and distributions based on it.

I apologize if this isn't the right place to create the issue, but issues weren't active on the build-extra repo.

Where is the 1.9.5 release on this project? I can only find the installer at https://msysgit.github.io/

What about the portable release?

• More robust downloading sschuberth/mgwport#3
• Deterministic build patches sschuberth/mgwport#2
• Add port file sschuberth/mgwport@f3d97fc
• Create package

Playing around with the new development environment a bit, I found the following issues with mintty:

Issues with git / msys programs:

• PR #102: automatic paging doesn't work in a second shell window (opened via Alt+F2, 'start mintty', 'mintty &', 'git-bash' etc.)
• d56d2f8: password prompt doesn't work in a second shell window (or goes to the wrong window)
• d56d2f8: password prompt no longer works in a native console window (due to new "mintty-aware" git_terminal_prompt checking for TERM=xterm)

Issues with other (native) console programs:

• non-ASCII characters don't work (e.g. cmd /? mangles äöü...)
• automatic paging doesn't work (e.g. cmd /?)
• cursor keys don't work (e.g. in cmd subshell)
• console screen buffer doesn't work (e.g. Far Manager)

The following packages need a security update:

• curl
• mingw32-openssl and msys-openssl
• bash

I'm running the developer's preview release and the wincred helper seems to be missing:
git: 'credential-wincred' is not a git command. See 'git --help'

Not a big problem since it can be easily worked around using something like git-credential-winstore, but figured it should be fixed before a real release.

@sschuberth pointed out that Git's documentation was recently adjusted to support being compiled using asciidoctor. It might speed up the generation substantial for us. Alternatively, we should look into using MinGW Python (as opposed to MSys2 Python) to run asciidoc.

This because we didn't install libgnutls

The current version of the script to build the self-extracting archive for the SDK requires to be run from an existing installation of the SDK (or at least from an existing MSYS2-based portable installation), which creates sort of a chicken-and-egg problem.

It would be nice if the script would instead "bootstrap" the required files (e.g. by downloading and extracting the required pacman packages via wget to some chroot-like environment). This would allow to build the SDK's self-extracting archive from e.g. MSYS1, or even on Linux (provided that 7-Zip is installed).

At the moment, Git for Windows' strategy is to convert the entire environment to UTF-8 wholesale at startup, and for performance reasons, keep the environment sorted so that lookups can be more efficient.

As has been found out recently the hard way, the underlying assumption that Git's own code is the exclusive user of the environment is not only fragile but incorrect: for example, cURL uses and modifies the environment as well.

So let's revisit the strategy to modify the environment. One viable option is to intercept both getenv() and putenv() in Git code to keep the real environment encoded in the current code page, but convert transparently from/to UTF-8 so that Git itself only sees Unicode values. This could be sped up considerably by testing whether the value in question is pure ASCII (which it will be in most cases) and skip the conversion altogether.

If necessary, the converted values could be held in a hash map, but for long-running Git processes this would require a last-recently-used eviction scheme, incurring quite a bit of complexity. So let's do that only if it turns out that the performance without this cache is not good enough.

The most important part of this ticket is to come up with a realistic benchmark. The best way in this developer's opinion would be to record all the calls to the environment conversion as well as to getenv() and putenv(), as performed by a complete test suite run, and condense those calls into a single benchmark program.

Currently we have "swapped" the MSYS and MinGW directory trees via a profile.xml to match what we had for msysgit. However, it makes more sense for us to simplify things by aligning the directory layout again with upstream MSYS.

I already started to populate https://git-for-windows.github.io/ with a website modified from https://msysgit.github.io/.

To finalize this ticket, we need to

• release a new installer generated using the new Git for Windows SDK
• replace msysgit.github.io by a redirect to the new home page
• notify the readers of the Git mailing lists of the switch
• add a note to the msysGit repositories

either disable it or enable it, for enable it, we need
Git\git-cheetah\git_shell_ext64.dll
Git\git-cheetah\git_shell_ext.dll.new

This is a big problem that also extends to suspending via Ctrl+Z. The problem is that the processes spawned by git clone (git-remote-https and git-fetch-pack) continue running unfazed when the main process is interrupted or suspended.

This happens only when git clone was started in mintty, though, and a workaround is to call winpty git clone.

When trying to run the installer git-sdk-64-installer-preview.7z.exe from https://github.com/git-for-windows/build-extra/releases/tag/net-installer-preview-1 the setup fails with the message bash: __git_ps1: command not found.

You can find the full log at https://gist.github.com/kappa7194/fe652bef133f6f511c10

Please verify the https can really getting clone or pulled,

There is a stub, but it needs to be fleshed out.

The right place should be C:\Program Files\Git

@kblees pointed out that MSys2-based Git for Windows is not compiled with nedmalloc enabled. That is most likely caused by an oversight of yours truly when porting MSys2's Git patches over to Git for Windows proper.

This is an excellent opportunity to revisit the nedmalloc performance.

I am looking into using MSys2 for future Git for Windows development, for a couple of reasons:

• MSys2 packages are much more up-to-date than MSys ones
• MSys2 offers a nice, stable package management system, pacman (ported from Arch Linux)
• MSys2 already ships with mintty, a powerful alternative to the cmd.exe command-line window
• MSys2 has 64-bit support
• MSys2 allows us to (re-)build Perl with Subversion bindings easily (at least that is the impression I got)

This ticket mainly serves as a notepad listing quirks and issues I find out while working on getting Git for Windows to build with MSys2.

It is quite easy to get started with MSys2:

1. download and install MSys2 as mentioned on https://msys2.github.io/
2. run the MINGW shell (not the MSys2 shell) from the Start Menu
3. run pacman -Sy git mingw-w64-x86_64-gcc to install Git and GCC (-S means "synchronize", i.e. install, and -y does not mean "yes" but "refresh the package list before installing the newest versions of the specified packages")
4. clone https://github.com/git-for-windows/MINGW-packages, say, into /usr/src/
5. in MINGW-packages/mingw-w64-git/, run makepkg-mingw -s (the -s says: install all dependencies, including build time dependencies, via pacman)
6. Play with the unpacked sources (they are in the src/build-x86_64/ or the src/build-i686/ subdirectory)

So it looks that it is pretty easy to get started, as well as to rebuild the MSys2 installer (which we might want to do in order to continue offering a net installer to contributors that avoids requiring manual steps).

Having said that, there are a few bumps on the road to heave: The following issues need to be solved before we can start bundling up even so much as a portable application:

• tab completion in the MSys2 shell seems to be flakey (it sometimes does not find anything, and pressing the Tab key repeatedly will not do anything in that case, but often it helps to delete the last character, retype it, and then press the Tab key again). This did not happen with the MinGW shell, funnily enough, so it might not be a huge problem for us; However, it could indicate a more problematic, deeper bug
• MSys2's openssh refuses to heed the HOME variable and always looks into /home/.ssh/
• MinGW Git built with makepkg-mingw hardcodes the absolute exec path (e.g. C:/msys64/mingw64/git-core)
• it seems that git ls-remote origin, run from a freshly-built and installed MinGW Git fails to be able to output anything, and git ls-remote origin | cat (a trick learned from working with old MSys'/MinGW's quirks) only says: output is not a tty (the exit code is 127, suggesting that some executable was not found, but it is very difficult to say which one because not even debug print statements to stderr are shown; It seems that in case of a crash or of a die(), stderr is not flushed)
• we #define some S_* flags in mingw.h that mingw-w64's headers already define. This results in tons of compile warnings that might hide valid problems
• MSys2's build recipe (called PKGBUILD; very similar to msysGit's home-brewn release.sh scripts) lists a dozen patches; We need to determine whether to reject them or whether to integrate them in our Git fork proper)
• MSys2 builds Git with ./configure while our strategy has always been to enhance the configuration in config.mak.uname; We need to decide whether we want to follow the ./configure strategy or rather continue with our tried and tested approach
• the mingw-w64-x86_64-gdb package is a 64-bit executable, but handles only 32-bit executables, it seems. This will make debugging substantially harder
• we will also need to add support for the -f flag to MSys2's kill command (Note: MSys2's kill already knows the -f flag, but there is a Bash builtin that takes precedence when calling kill without an explicit path, and that kill does not know the -f flag)

I will keep updating this report as I find out more.

I was just trying to figure out which components I wanted to install out of the dizzying array available, and after making some changes I wanted to start over because I wasn't sure exactly what I might have changed. Unfortunately, there was no "reset to default" button available, and the window did not want to close. I ended up having to kill the process tree to start over.

$ sh
sh: __git_ps1: 未找到命令

I got unknown option 'refresh error, when using git 2.3.5.
I installed using net-installer:
https://github.com/git-for-windows/build-extra/releases/tag/net-installer-1.0.0-rc-1

git --version
git version 2.3.5.windows.2.1.g9a5c96c

git.exe checkout "lib_dev"
Already on 'lib_dev'
Your branch is up-to-date with 'lib/dev'.
'rror: unknown option 'refresh
usage: git update-index [options] [--] [...]

-q                    continue refresh even when index needs update
--ignore-submodules   refresh: ignore submodules
--add                 do not ignore new files
--replace             let files replace directories and vice-versa
--remove              notice files missing from worktree
--unmerged            refresh even if index contains unmerged entries
--refresh             refresh stat information
--really-refresh      like --refresh, but ignore assume-unchanged setting
--cacheinfo <mode>,<object>,<path>
                      add the specified entry to the index
--chmod (+/-)x        override the executable bit of the listed files
--assume-unchanged    mark files as "not changing"
--no-assume-unchanged
                      clear assumed-unchanged bit
--skip-worktree       mark files as "index-only"
--no-skip-worktree    clear skip-worktree bit
--info-only           add to index only; do not add content to object database
--force-remove        remove named paths even if present in worktree
-z                    with --stdin: input lines are terminated by null bytes

--stdin               read list of paths to be updated from standard input
--index-info          add entries from standard input to the index
--unresolve           repopulate stages #2 and #3 for the listed paths
-g, --again           only update entries that differ from HEAD
--ignore-missing      ignore files missing from worktree
--verbose             report actions to standard output
--clear-resolve-undo  (for porcelains) forget saved unresolved conflicts
--index-version <n>   write index in this format
--split-index         enable or disable split index

Any idea what is the problem?

After opening up up PortableGit (using a git-bash.bat file to keep the settings portable per http://stackoverflow.com/a/3455231/647393 - which by the way should be standard for PortableGit IMO), I found that my $PATH looks like this:
//bin:.:/usr/local/bin:/mingw/bin:/bin:/c/Misc/ConEmu/ConEmu:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/c/Program Files (x86)/ATI Technologies/ATI.ACE/Core-Static:/c/Program Files (x86)/Heroku/bin:/c/Program Files (x86)/git/cmd:/c/Program Files (x86)/Java/jre7/bin: C:/Misc/PortablePython-2.7.5.1/App/Scripts

The last path looks different than the rest and therefore doesn't work, and I don't know why. The last two are both part of the user PATH environment variable in Windows 7 but the Java one doesn't get converted into C:/ rather than /c/.

I was able to fix this by editing .bash_profile to append :/c/misc/portablepython-2.7.5.1/app/scripts which works. Incidentally .bash_profile works but .bashrc does not work, which seems opposite of what I'd expect per .bash_profile only applying to "login shells" per http://stackoverflow.com/questions/415403/whats-the-difference-between-bashrc-bash-profile-and-environment.

Besides, as reported by @kblees (in person), TEMP points to /tmp which is inside Program Files/ in end-user installations.

The information about which files are builtins is very valuable, e.g. when instaling Git onto a filesystem that supports hardlinks.

I think it would be nice if the default Vim installation when installing Git for Windows could be updated to 7.4.691, as patches past 7.4.674 fixes some issues, and also changes some things.