I'm trying to write some vimscript that will communicate with dubuggers, but I'm not entirely sure how to go about doing it. Is there a way I can send input to a debugger and read its output programatically?
I know this is possible because Code::Blocks, Eclipse, and other IDEs do this somehow. I'm just wondering how it can be done.
I'm just wondering how it can be done.
GDB has "machine interface" just for that. Details here.
Git 2.18 shows an interesting way to wrap and communicate with a debugger, gdb or others.
See commit 8424364 (24 Apr 2018) by Elijah Newren (newren).
(Merged by Junio C Hamano -- gitster -- in commit 89753dc, 23 May 2018)
Make running git under other debugger-like programs easy
This allows us to run git, when using the script from bin-wrappers, under
other programs.
A few examples for usage within testsuite scripts:
debug git checkout master
debug --debugger=nemiver git $ARGS
debug -d "valgrind --tool-memcheck --track-origins=yes" git $ARGS
Or, if someone has bin-wrappers/ in their $PATH and is executing git outside the testsuite:
GIT_DEBUGGER="gdb --args" git $ARGS
GIT_DEBUGGER=nemiver git $ARGS
GIT_DEBUGGER="valgrind --tool=memcheck --track-origins=yes" git $ARGS
There is also a handy shortcut of GIT_DEBUGGER=1 meaning the same as
GIT_DEBUGGER="gdb --args"
See the result in t/test-lib-functions.sh.
About that GIT_DEBUGGER, Git 2.23 documents it.
See commit f547101 (28 May 2019) by Emily Shaffer (nasamuffin).
(Merged by Junio C Hamano -- gitster -- in commit 7df94cd, 17 Jun 2019)
doc: hint about GIT_DEBUGGER in CodingGuidelines
We check for a handy environment variable GIT_DEBUGGER when running via
bin-wrappers/, but this feature is undocumented.
Add a hint to how to use it into the CodingGuidelines (which is where other useful environment settings like DEVELOPER are documented).
So Documentation/CodingGuidelines now includes:
You can launch gdb around your program using the shorthand GIT_DEBUGGER.
Run GIT_DEBUGGER=1 ./bin-wrappers/git foo to simply use gdb as is, or
run GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo to
use your own debugger and arguments.
Example: GIT_DEBUGGER="ddd --gdb" ./bin-wrappers/git log (See wrap-for-bin.sh.)
Related
What is the cause and resolution for the git warning message "Empty last update token."?
I have a repository, where every command prints this warning, e.g.
$ git status
warning: Empty last update token.
On branch foo
Your branch is up to date with 'origin/foo'.
$ git fetch
warning: Empty last update token.
$ git reset --hard
warning: Empty last update token.
Updating files: 100% (79/79), done.
HEAD is now at e1c42a2 blah
$ git prune
warning: Empty last update token.
The commands still seem to succeed. The warning message totally confuses external tools like git-extensions though, which shows "unresolved merge conflicts" when git status contains any unexpected output.
The problem only occurs with the local repository on one specific pc, but copying the .git folder to a different pc reproduces the problem.
I could delete the local copy and start fresh, but I would like to determine the cause, and perhaps even save the stashes.
#kaveman is right, this is evidently the new filesystem monitoring daemon that got built into git for Windows and Mac OS in 2.37. When I enabled with core.fsMonitor = true in my .gitconfig, git 2.35.1 printed this same Empty last update token warning. After I upgraded to git 2.37, the warning disappeared.
This isn't a great answer, but it got rid of the error message for me:
Check if core.fsMonitor is on:
$ git config core.fsMonitor
true
And if true, turn it off:
$ git config core.fsMonitor false
$ git config core.fsMonitor
false
Potentially more information on this thread: https://public-inbox.org/git/4aa1293e-00b6-b9ef-efd4-cdf605db37a1#jeffhostetler.com/
Note: on Mac, fsmonitor might work better with Git 2.39 (Q4 2022): by default, use of fsmonitor on a repository on networked filesystem is disabled.
Add knobs to make it workable on macOS.
See commit c4f9490 (10 Oct 2022) by Jeff King (peff).
See commit 5aa9e32, commit 25c2cab, commit 12fd27d, commit 8f44976, commit 6beb268, commit 508c1a5 (04 Oct 2022) by Eric DeCosta (edecosta-mw).
(Merged by Junio C Hamano -- gitster -- in commit 7b8cfe3, 17 Oct 2022)
fsmonitor: deal with synthetic firmlinks on macOS
Signed-off-by: Eric DeCosta
Starting with macOS 10.15 (Catalina), Apple introduced a new feature called 'firmlinks' in order to separate the boot volume into two volumes, one read-only and one writable but still present them to the user as a single volume.
Along with this change, Apple removed the ability to create symlinks in the root directory and replaced them with 'synthetic firmlinks'.
See 'man synthetic.conf'
When FSEevents reports the path of changed files, if the path involves a synthetic firmlink, the path is reported from the point of the synthetic firmlink and not the real path.
For example:
Real path: /System/Volumes/Data/network/working/directory/foo.txt
Synthetic firmlink: /network -> /System/Volumes/Data/network
FSEvents path: /network/working/directory/foo.txt
This causes the FSEvents path to not match against the worktree directory.
There are several ways in which synthetic firmlinks can be created: they can be defined in /etc/synthetic.conf, the automounter can create them, and there may be other means.
Simply reading /etc/synthetic.conf is insufficient.
No matter what process creates synthetic firmlinks, they all get created in the root directory.
Therefore, in order to deal with synthetic firmlinks, the root directory is scanned and the first possible synthetic firmink that, when resolved, is a prefix of the worktree is used to map FSEvents paths to worktree paths.
In addition, Git 2.39 (Q4 2022) also enables macOS build with sha1dc hash function.
See commit 3220565 (19 Oct 2022) by Ævar Arnfjörð Bjarmason (avar).
(Merged by Junio C Hamano -- gitster -- in commit cc75743, 21 Oct 2022)
fsmonitor OSX: compile with DC_SHA1=YesPlease
Signed-off-by: Eric DeCosta
Signed-off-by: Ævar Arnfjörð Bjarmason
As we'll address in subsequent commits the "DC_SHA1=YesPlease" is not on by default on OSX, instead we use Apple Common Crypto's SHA-1 implementation.
In 6beb268 ("fsmonitor: relocate socket file if .git directory is remote", 2022-10-04, Git v2.39.0 -- merge listed in batch #3) the build was broken with "DC_SHA1=YesPlease" (and probably other non-"APPLE_COMMON_CRYPTO" SHA-1 backends).
So let's extract the fix for this from this thread to get the build working again with "DC_SHA1=YesPlease".
In addition to the fix in [1] we also need to replace "SHA_DIGEST_LENGTH" with "GIT_MAX_RAWSZ".
Actually, still with 2.39 (Q4 2022), DC_SHA1 is the default:
See commit d00fa55, commit fb8d7ad, commit dc1cf35, commit ed605fa, commit 84d71c2, commit f569897, commit 34b660e, commit b425ba2, commit 0ced11d, commit e47913e (07 Nov 2022) by Ævar Arnfjörð Bjarmason (avar).
(Merged by Taylor Blau -- ttaylorr -- in commit e53598a, 18 Nov 2022)
Makefile: document default SHA-1 backend on OSX
Signed-off-by: Ævar Arnfjörð Bjarmason
Signed-off-by: Taylor Blau
Since [1] the default SHA-1 backend on OSX has been APPLE_COMMON_CRYPTO.
Per [2] we'll skip using it on anything older than Mac OS X 10.4 "Tiger"[3].
When "DC_SHA1" was made the default in [4] this interaction between it and APPLE_COMMON_CRYPTO seems to have been missed in.
Ever since DC_SHA1 was "made the default" we've still used Apple's CommonCrypto instead of sha1collisiondetection on modern versions of Darwin and OSX.
6106795 (cache.h: eliminate SHA-1 deprecation warnings on Mac OS X, 2013-05-19, Git v1.8.4-rc0 -- merge) (cache.h: eliminate SHA-1 deprecation warnings on Mac
OS X, 2013-05-19)
9c7a0be (config.mak.uname: set NO_APPLE_COMMON_CRYPTO on older systems, 2014-08-15, Git v2.2.0-rc0 -- merge) (config.mak.uname: set NO_APPLE_COMMON_CRYPTO on older
systems, 2014-08-15)
We could probably drop "NO_APPLE_COMMON_CRYPTO", as nobody's likely
to care about such on old version of OSX anymore. But let's leave that
for now.
e6b07da ("Makefile: make DC_SHA1 the default", 2017-03-17, Git v2.13.0-rc0 -- merge listed in batch #7)
Still on the MacOS side, Git 2.40 (Q1 2023) will stop using deprecated macOS API in fsmonitor.
See commit b022600 (14 Dec 2022) by Jeff Hostetler (Jeff-Hostetler).
(Merged by Junio C Hamano -- gitster -- in commit 636de95, 19 Dec 2022)
fsmonitor: eliminate call to deprecated FSEventStream function
Signed-off-by: Jeff Hostetler
Replace the call to FSEventStreamScheduleWithRunLoop() function with the suggested FSEventStreamSetDispatchQueue() function.
The MacOS version of the builtin FSMonitor feature uses the FSEventStreamScheduleWithRunLoop() function to drive the event loop and process FSEvents from the system.
This routine has now been deprecated by Apple.
The MacOS 13 (Ventura) compiler tool chain now generates a warning when compiling calls to this function.
In DEVELOPER=1 mode, this now causes a compile error.
The FSEventStreamSetDispatchQueue() function is conceptually similar and is the suggested replacement.
However, there are some subtle thread-related differences.
Previously, the event stream would be processed by the fsm_listen__loop() thread while it was in the CFRunLoopRun() method.
(Conceptually, this was a blocking call on the lifetime of the event stream where our thread drove the event loop and individual events were handled by the fsevent_callback().)
With the change, a "dispatch queue" is created and FSEvents will be processed by a hidden queue-related thread (that calls the fsevent_callback() on our behalf).
Our fsm_listen__loop() thread maintains the original blocking model by waiting on a mutex/condition variable pair while the hidden thread does all of the work.
While the deprecated API used by the original were introduced in macOS 10.5 (Oct 2007), the API used by the updated code were introduced back in macOS 10.6 (Aug 2009) and has been available since then.
So this change could break those who have happily been using 10.5 (if there were such people), but these two dates both predate the oldest versions of macOS Apple seems to support anyway, so we should be safe.
With Git 2.40 (Q1 2023), use the SHA1DC implementation on macOS, just like other platforms, by default.
See commit 35898ad (15 Dec 2022) by Ævar Arnfjörð Bjarmason (avar).
(Merged by Junio C Hamano -- gitster -- in commit cd2cc44, 26 Dec 2022)
Makefile: use sha1collisiondetection by default on OSX and Darwin
Signed-off-by: Ævar Arnfjörð Bjarmason
When the sha1collisiondetection library was added and made the default in [1] the interaction with APPLE_COMMON_CRYPTO added in [2] and [3] seems to have been missed.
On modern OSX and Darwin we are able to use Apple's CommonCrypto both for SHA-1, and as a generic (but partial) OpenSSL replacement.
This left OSX and Darwin without protection against the SHAttered attack when building Git in its default configuration.
Let's also use sha1collisiondetection on OSX, to do so we'll need to split up the "APPLE_COMMON_CRYPTO" flag into that flag and a new "APPLE_COMMON_CRYPTO_SHA1".
Because of this we can stop conflating whether we want to use Apple's CommonCrypto at all, and whether we want to use it for SHA-1.
This makes the CI recipe added in [4] simpler.
e6b07da ("Makefile: make DC_SHA1 the default", 2017-03-17, Git v2.13.0-rc0 -- merge listed in batch #7)
4dcd773 ("Makefile: add support for Apple CommonCrypto facility", 2013-05-19, Git v1.8.4-rc0 -- merge)
6106795 ("cache.h: eliminate SHA-1 deprecation warnings on Mac OS X", 2013-05-19, Git v1.8.4-rc0 -- merge)
1ad5c3d (ci: use DC_SHA1=YesPlease on osx-clang job for CI, 2022-10-20, Git v2.39.0-rc0 -- merge listed in batch #6)
I'm using mintty via Git-for-Windows and CPython35-32. Why does Python think it's not attached to a terminal?
$ python -c "import sys; print(sys.stdout.isatty())"
False
Interestingly, I also have a problem that I can not start an interactive session of Python inside the mintty. It might be related to this issue
$ python
<nothingness here...>
mintty's console emulation uses pipes to emulate a tty behind the scenes which confuses native programs checking to see if they are attached to a tty. In your case Python's isatty() sees stdout as being attached to pipe due to the fake tty and returns False.
This is another example of mintty issue #56 - Improve support for native console programs. The mintty wiki entry "Input/Output interaction with alien programs" points out you can work around the problem by using a wrapper like winpty when running the problem program within mintty.
The git commits mentioned by #vonc only work around the problem in the git program itself - they won't impact other programs (such as Python running in git-for-window's mintty) which would need to implement git's workaround in their own source.
You might want to try that with Git 2.12 (Q1 2017)
See commit a9b8a09 (22 Dec 2016) by Jeff Hostetler (jeffhostetler).
See commit 8692483 (22 Dec 2016) by Alan Davies (scooter6386).
See commit fee807c (22 Dec 2016) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit 58fcd54, 27 Dec 2016)
mingw: replace isatty() hack
Git for Windows has carried a patch that depended on internals of MSVC runtime, but it does not work correctly with recent MSVC runtime.
A replacement was written originally for compiling with VC++.
The patch in this message is a backport of that replacement, and it also fixes the previous attempt to make isatty() tell that /dev/null is not an interactive terminal.
The versions of OpenSSH & OpenSSL in Git Bash are really old. As of this posting, when inputting ssh -V the versions are:
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
My question is, how do we upgrade these (safely, without breaking anything, etc.)? This article has a solution, but it only mentions upgrading OpenSSH, not OpenSSL, although I'm sure you could find OpenSSL files to transfer as well. However, it requires installing Cygwin, which may not be wanted. There is a way to download the Cygwin modules but not install them, though, but this does not seem to add some DLL's like cygcrypto.dll & cygwin1.dll.
Even if this works, is there another way? Can you just download some files from openssh.com/openssl.org and change a couple config files?
Note: the last Git for Windows release (the Git 2.12.1, March 2017) uses now a much more recent OpenSSL version.
The Windows port uses now OpenSSL's implementation of SHA-1 routines
See commit 2cfc70f (09 Feb 2017) by Jeff Hostetler (jeffhostetler).
(Merged by Junio C Hamano -- gitster -- in commit 033328a, 13 Mar 2017)
mingw: use OpenSSL's SHA-1 routines
Use OpenSSL's SHA-1 routines rather than builtin block-sha1 routines.
This improves performance on SHA1 operations on Intel processors.
OpenSSL 1.0.2 has made considerable performance improvements and
support the Intel hardware acceleration features.
C:\tools\gits\latest\usr\bin>openssl version
OpenSSL 1.0.2k 26 Jan 2017
See:
(Intel) Improving OpenSSL Performance
Intel® SHA Extensions
And yes, OpenSSH is more recent too:
C:\tools\gits\latest\usr\bin>ssh -V
OpenSSH_7.3p1, OpenSSL 1.0.2k 26 Jan 2017
UPDATE:
This is the file list i am using at the moment to make cygwin ssh work with git bash.
From the cygwin installation directory, copy the below filelist to your git bash
installation directory.
Be aware, if you have configured ~/.ssh/config then you need to set correct permissions from cygwin for ssh to work properly.
cygasn1-8.dll
cygattr-1.dll
cygbz2-1.dll
cygcom_err-2.dll
cygcrypt-0.dll
cygcrypto-1.0.0.dll
cygedit-0.dll
cygform-10.dll
cygformw-10.dll
cyggcc_s-1.dll
cyggmp-10.dll
cyggmp-3.dll
cyggssapi-3.dll
cygheimbase-1.dll
cygheimntlm-0.dll
cyghistory7.dll
cyghx509-5.dll
cygiconv-2.dll
cygintl-8.dll
cygkafs-0.dll
cygkrb5-26.dll
cyglsa.dll
cyglsa64.dll
cyglua-5.1.dll
cyglzma-5.dll
cygmagic-1.dll
cygmenu-10.dll
cygmenuw-10.dll
cygmp-3.dll
cygmpfr-4.dll
cygncurses++-10.dll
cygncurses++w-10.dll
cygncurses-10.dll
cygncursesw-10.dll
cygpanel-10.dll
cygpanelw-10.dll
cygpcre-0.dll
cygpcre-1.dll
cygpopt-0.dll
cygreadline7.dll
cygroken-18.dll
cygsqlite3-0.dll
cygssl-1.0.0.dll
cygssp-0.dll
cygstdc++-6.dll
cygtic-10.dll
cygticw-10.dll
cygwin1.dll
cygwind-0.dll
cygwrap-0.dll
cygz.dll
ssh-add.exe
ssh-agent.exe
ssh-copy-id
ssh-host-config
ssh-keygen.exe
ssh-keyscan.exe
ssh-user-config
ssh.exe
sshfiles
Sometimes a git checkout command gives progress feedback:
$ git checkout develop
Checking out files: 100% (10779/10779), done.
Switched to branch 'develop'
Sometimes it doesn't, (very next command line, same repo context):
$ git checkout master
Switched to branch 'master'
It's not because the branches are equal, because switching back on the very next command shows this feedback:
$ git checkout develop
Checking out files: 47% (5067/10779), done.
Switched to branch 'develop'
This happens for small repos also. I have a repo with just 13 files in it and when I add a file in a branch and use checkout to switch back and forth, I get no feedback either way. Is it some kind of "this is taking a long time, start showing feedback" timer?
I searched (Google, Stackoverflow) but didn't find anything specific. I did find some patch documentation that shows the addition of a --verbose flag to checkout that forces feedback to always happen, but I couldn't find an explanation for why feedback only happens sometimes without that patch. The same notes pointed out that feedback only happens if isatty() returns true, but that's not relevant here, since all of the commands above were typed into the same bash window, which presumably isatty.
I'm using git version 1.8.1.msysgit.1 (downloaded from git-scm.com as 1.8.1.3), which does not have the --verbose patch as far as I can tell.
This checkout output should now be more consistent with Git 2.7 (Nov./Dec. 2015)
See commit 870ebdb (01 Nov 2015) by Edmundo Carmona Antoranz (eantoranz).
(Merged by Junio C Hamano -- gitster -- in commit 6a38bd6, 05 Nov 2015)
"git checkout" did not follow the usual "--[no-]progress" convention and implemented only "--quiet" that is essentially a superset of "--no-progress".
Extend the command to support the usual "--[no-]progress".
The git checkout doc now shows:
--[no-]progress::
Progress status is reported on the standard error stream by default when it is attached to a terminal, unless --quiet is specified.
This flag enables progress reporting even if not attached to a terminal, regardless of --quiet.
checkout: add --progress option
Under normal circumstances, and like other git commands, git checkout will write progress info to stderr if attached to a terminal.
This option allows progress to be forced even if not using a terminal.
Also, progress can be skipped if using option --no-progress.
Under normal conditions, you will see output when checking out if the operation's been running for more than one second.
It doesn't look like git-p4 is part of the MSys-Git project for Windows. Does anybody know how to get it running through Windows?
Update July 2019, the "Git P4 clone broken" question now mentions by Gabriel Morin:
[alias]
p4 = !python.exe 'c:\\program files\\Git\\mingw64\\libexec\\git-core\\git-p4'
Then using git p4 from the command line worked.
With Git 2.32 (Q2 2021), git p4 learned to find branch points more efficiently.
See commit 6b79818, commit c3ab088 (05 May 2021) by Joachim Kuebart (jkuebart).
(Merged by Junio C Hamano -- gitster -- in commit e289f68, 14 May 2021)
git-p4: speed up search for branch parent
Signed-off-by: Joachim Kuebart
Helped-by: Junio C Hamano
Helped-by: Luke Diamand
For every new branch that git-p4 imports, it needs to find the commit where it branched off its parent branch.
While p4 doesn't record this information explicitly, the first changelist on a branch is usually an identical copy of the parent branch.
The method searchParent() tries to find a commit in the history of the given "parent" branch whose tree exactly matches the initial changelist of the new branch, "target".
The code iterates through the parent commits and compares each of them to this initial changelist using diff-tree.
Since we already know the tree object name we are looking for, spawning diff-tree for each commit is wasteful.
Use the "--format" option of "rev-list" to find out the tree object name of each commit in the history, and find the tree whose name is exactly the same as the tree of the target commit to optimize this.
This results in a considerable speed-up, at least on Windows.
On one Windows machine with a fairly large repository of about 16000 commits in the parent branch, the current code takes over 7 minutes, while the new code only takes just over 10 seconds for the same changelist:
Before:
$ time git p4 sync
Importing from/into multiple branches
Depot paths: //depot
Importing revision 31274 (100.0%)
Updated branches: b1
real 7m41.458s
user 0m0.000s
sys 0m0.077s
After:
$ time git p4 sync
Importing from/into multiple branches
Depot paths: //depot
Importing revision 31274 (100.0%)
Updated branches: b1
real 0m10.235s
user 0m0.000s
sys 0m0.062s
Update March 2020
With Git 2.27 (Q2 2020), "git p4" is updated to work with Python 3.
See commit 6bb40ed (23 Jan 2020) by SZEDER Gábor (szeder).
See commit 7575f4f, commit ce425eb, commit 2e2aa8d, commit a6b1306, commit 4294d74, commit 50da1e7, commit 5a5577d, commit d38208a, commit 86dca24, commit 6cec21a, commit 1f8b46d, commit 0b4396f (13 Dec 2019) by Yang Zhao (yangminz).
See commit 484d09c (13 Dec 2019) by Ben Keene (seraphire).
(Merged by Junio C Hamano -- gitster -- in commit 9a0fa17, 25 Mar 2020)
ci: use python3 in linux-gcc and osx-gcc and python2 elsewhere
Signed-off-by: SZEDER Gábor
Python2 reached end of life, and we have been preparing our Python scripts to work with Python3.
'git p4', the main in-tree user of Python, has just received a number of compatibility updates.
This is documented only with Git 2.30 (Q1 2021) in commit 263dc0.
Update July 2018:
Git 2.19 (Q3 2018) will start bringing Python 3 support to git p4.
See commit db2d997, commit f2606b1, commit efdcc99, commit 4d88519, commit dba1c9d, commit fc35c9d (19 Jun 2018) by Luke Diamand (luked99).
(Merged by Junio C Hamano -- gitster -- in commit 6dcd364, 18 Jul 2018)
Code preparation to make "git p4" closer to be usable with Python 3.
Update January 2016:
Since 2010, contrib/fast-import/git-p4.README mentions since April 2012
The git-p4 script moved to the top-level of the git source directory.
Note that the top-level git-p4.py script is now the source
Windows users can copy the git-p4.py source script directly, possibly
invoking it through a batch file called "git-p4.bat" in the same folder.
It should contain just one line:
#python "%~d0%~p0git-p4.py" %*
(Although this 2013 article is invoking git-p4.py directly)
Original answer (April 2010)
As mention in "Why Perforce is more scalable than Git", be careful to not import in Git any p4 repo. Git cannot handle the same kind of huge unique repo P4 can manage.
Git-P4 being in Python, it should run on Windows (like in this question)
You can grab git-p4.py here and use this as git-p4.bat
#python "%~d0%~p0git-p4" %*
It requires a Python 2.x installed.
Don't forget there is another approach as well.
The simplest answer I found, and seems to work flawlessly so far, was on Timo Geusch's blog:
Make sure you have Python 2.X installed, eg in C:\Python27 (dunno if git-p4 supports Python 3, so I didn't risk it git-p4.py does not support Python 3.X, as of March 2014)
Get a copy of git-p4.py from anywhere, eg as Eric Lathrop's blog post suggests, from the git repo directly (I got mine from a linux install of git 2.1 that I happened to have already set up)
In your MSysGit installation, navigate to libexec\git-core, eg on my Git for Windows 1.9.4-preview20140611 install on windows 7 64-bit that is C:\Program Files (x86)\Git\libexec\git-core
Drop your git-p4.py file there
At that same location, edit the "git-p4" extensionless file, replacing the dummy echo and exit lines with a single line
c:/python27/python "c:/program files (x86)/Git/libexec/git-core/git-p4.py" $1 $2 $3 $4 $5 $6 $7 $8 $9
That's it. git-p4 now works on your MSysGit / Git for Windows installation just like it does on any linux box.
(please note, Eric Lathrop's existing answer has a lot of additional information about working with git-p4 and all its limitations; I thought this question could benefit from a simple howto answer to the actual question though, i.e. easily getting it working on Windows, lest more wanderers be discouraged as I was last week)
I got it to work, but it was a long, arduous process, fraught with peril. I wrote up the instructions on my blog: http://ericlathrop.com/2012/12/how-to-set-up-git-p4-in-windows/
After reading https://git-scm.com/docs/git-p4
py -2 "C:\Program Files\Git\mingw64\libexec\git-core\git-p4" clone //Projects/App/#all
Worked for me