remote-hg: adjust to hg 1.9

hg 1.0 changed the signature of hg.clone(). Adjust to it.

A real fix would need to check the hg version or try/catch.
git-remote-hg: add the helper

The helper uses the previously added infrastructure.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
git-remote-hg: add tests
remote-hg: Postel's law dictates we should handle Author<author@mail>

We should handle a missing space before the email part of an author ident
gracefully. See for example the icedtea6 repository.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
remote-hg: another case of Postel's law

This change allows invalid input from Mercurial repositories where the
author is recorded as 'Name <email@blah' (missing the closing '>').

With this change, importing http://scelenic.com/hg itself no longer fails
with:

	fatal: Missing > in ident string: Benoit Boissinot
	<benoit.boissinot@ens-lyon.org <none@none> 1129685868 -0700

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
remote-hg: handle another funny author line from http://scelenic.com/hg

In this case: David Soria Parra <dsp <at> php.net>.

With this last of three Postel patches, remote-hg can import the
Mercurial repository completely.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
remote-hg: do not interfer with hg's revs() method

Matt Mackall introduced a revs() method to the localrepo class on Wed
Nov 2 13:37:34 2011 in the commit 'localrepo: add revs helper method'.
It is used when constructing a commit in memory.

If we store the set of revs we want to handle under the same name, it
overrides that method, resulting in an unpleasant 'TypeError: 'set'
object is not callable' whenever we want to push (as we are constructing
commits in memory, then).

So let's work around that by renaming our field to 'revs_' and hope that
upstream Mercurial does not introduce a field of that name, too.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Always auto-gc after calling a fast-import transport

After importing anything with fast-import, we should always let the
garbage collector do its job, since the objects are written to disk
inefficiently.

This brings down an initial import of http://selenic.com/hg from about
230 megabytes to about 14.

In the future, we may want to make this configurable on a per-remote
basis, or maybe teach fast-import about it in the first place.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
t5801: skip without hg

The tests for remote-hg require hg, so skip them all when there is no
hg available.
t1050: Fix invalid call to dd(1)

This is a companion patch to fce52b4(t4012: Fix invalid call to dd(1)).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Work around a problem identified by BuildHive

Apparently the signal handling is not quite correct in the fsckobject
handling (most likely we rely on a side effect that lets us still output
some message after receiving a signal 13 but in the BuildHive setup this
fails intermittently).

As a consequence, the push in t5504 does fail as expected, but fails to
output anything (unexpected). Since this is good enough for now, let's
handle an empty output as success, too.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Sleep 1 millisecond in poll() to avoid busy wait

I played around with this quite a bit. After trying some more complex
schemes, I found that what worked best is to just sleep 1 millisecond
between iterations. Though it's a very short time, it still completely
eliminates the busy wait condition, without hurting perf.

There code uses SleepEx(1, TRUE) to sleep. See this page for a good
discussion of why that is better than calling SwitchToThread, which
is what was used previously:
http://stackoverflow.com/questions/1383943/switchtothread-vs-sleep1

Note that calling SleepEx(0, TRUE) does *not* solve the busy wait.

The most striking case was when testing on a UNC share with a large repo,
on a single CPU machine. Without the fix, it took 4 minutes 15 seconds,
and with the fix it took just 1:08! I think it's because git-upload-pack's
busy wait was eating the CPU away from the git process that's doing the
real work. With multi-proc, the timing is not much different, but tons of
CPU time is still wasted, which can be a killer on a server that needs to
do bunch of other things.

I also tested the very fast local case, and didn't see any measurable
difference. On a big repo with 4500 files, the upload-pack took about 2
seconds with and without the fix.
Provide a Windows version resource for the git executables.

Embeds the git version and description into the git executable thus
implementing the request in issue #5.

Acked-by: Heiko Voigt <hvoigt@hvoigt.net>
Acked-by: Sebastian Schuberth <sschuberth@gmail.com>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Windows resource: handle dashes in the Git version gracefully

Reported by postiffm as issue #14.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Ensure the resource file is rebuilt when the version changes.

Acked-by: Erik Faye-Lund <kusmabite@gmail.com>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Make non-.exe externals work again

7ebac8cb94f3a06d3fbdde469414a1443ca45510 made launching of .exe
externals work when installed in Unicode paths. But it broke launching
of non-.exe externals, no matter where they were installed. We now
correctly maintain the UTF-8 and UTF-16 paths in tandem in lookup_prog.

This fixes t5526, among others.

Signed-off-by: Adam Roben <adam@roben.org>
Set the default help format to html for msys builds.

This resolves issue #19 by setting the compiled default to html in msys
builds following the changes introduced by commit
1cc8af0 "help: use HTML as the default help format on Windows"

Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
help: correct behavior for is_executable on Windows

The previous implementation said that the filesystem information on
Windows is not reliable to determine whether a file is executable.
To find gather this information it was peeking into the first two bytes
of a file to see whether it looks executable.
Apart from the fact that on Windows executables are usually defined as
such by their extension it lead to slow opening of help file in some
situations.

When you have virus scanner running calling open on an executable file
is a potentially expensive operation. See the following measurements (in
seconds) for example.

With virus scanner running (coldcache):

$ ./a.exe /libexec/git-core/
before open (git-add.exe): 0.000000
after open (git-add.exe): 0.412873
before open (git-annotate.exe): 0.000175
after open (git-annotate.exe): 0.397925
before open (git-apply.exe): 0.000243
after open (git-apply.exe): 0.399996
before open (git-archive.exe): 0.000147
after open (git-archive.exe): 0.397783
before open (git-bisect--helper.exe): 0.000160
after open (git-bisect--helper.exe): 0.397700
before open (git-blame.exe): 0.000160
after open (git-blame.exe): 0.399136
...

With virus scanner running (hotcache):

$ ./a.exe /libexec/git-core/
before open (git-add.exe): 0.000000
after open (git-add.exe): 0.000325
before open (git-annotate.exe): 0.000229
after open (git-annotate.exe): 0.000177
before open (git-apply.exe): 0.000167
after open (git-apply.exe): 0.000150
before open (git-archive.exe): 0.000154
after open (git-archive.exe): 0.000156
before open (git-bisect--helper.exe): 0.000132
after open (git-bisect--helper.exe): 0.000180
before open (git-blame.exe): 0.000718
after open (git-blame.exe): 0.000724
...

This test did just list the given directory and open() each file in it.

With this patch I get:

$ time git help git
Launching default browser to display HTML ...

real    0m8.723s
user    0m0.000s
sys     0m0.000s

and without

$ time git help git
Launching default browser to display HTML ...

real    1m37.734s
user    0m0.000s
sys     0m0.031s

both tests with cold cache and giving the machine some time to settle
down after restart.

Signed-off-by: Heiko Voigt <heiko.voigt@mahr.de>
gitk: Use an external icon file on Windows

Git for Windows now ships with the new Git icon from git-scm.com. Use that
icon file if it exists instead of the old procedurally drawn one.

This patch was sent upstream but so far no decision on its inclusion was
made, so commit it to our fork.

Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
git stash: make sure that .git/logs/refs/ exists

If the user has not activated reflogs, or if nothing has been recorded
yet (as is the case directly after cloning), said directory may not
exist yet.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>