These fixes were necessary for Sverre Rabbelier's remote-hg to work,
but for some magic reason they are not necessary for the current
remote-hg. Makes you wonder how that one gets away with it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This patch teaches `git add -e` to truncate the patch file first (in
case that there is a left-over one from a previous, failed attempt).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This used to be "Merge pull request #938 from virtuald/patch-1"
git-cvsexportcommit.perl: Force crlf translation
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch adds the (experimental) --stdin/-z options to `git
reset`. Those patches are still under review in the upstream Git project,
but are already merged in their experimental form into Git for Windows'
`master` branch, in preparation for a MinGit-only release.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It has been reported that core.hideDotFiles=false stopped working...
This topic branch fixes it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
7ebac8cb94 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>
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>
If there is already a .git/ADD_EDIT.patch file, we fail to truncate it
properly, which could result in very funny errors.
Let's just truncate it and not worry about it too much.
Reported by J Wyman.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
If Git were installed in a path containing non-ASCII characters,
commands such as git-am and git-submodule, which are implemented as
externals, would fail to launch with the following error:
> fatal: 'am' appears to be a git command, but we were not
> able to execute it. Maybe git-am is broken?
This was due to lookup_prog not being Unicode-aware. It was somehow
missed in 2ee5a1a14a.
Note that the only problem in this function was calling
GetFileAttributes instead of GetFileAttributesW. The calls to access()
were fine because access() is a macro which resolves to mingw_access,
which already handles Unicode correctly. But I changed lookup_prog to
use _waccess directly so that we only convert the path to UTF-16 once.
Signed-off-by: Adam Roben <adam@roben.org>
When calling `git fast-export a..a b` when a and b refer to the same
commit, nothing would be exported, and an incorrect reset line would
be printed for b ('from :0').
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
This happens only when the corresponding commits are not exported in
the current fast-export run. This can happen either when the relevant
commit is already marked, or when the commit is explicitly marked
as UNINTERESTING with a negative ref by another argument.
This breaks fast-export basec remote helpers.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
When using cvsnt + msys + git, it seems like the output of cvs status
had \r\n in it, and caused the command to fail.
This fixes that.
Signed-off-by: Dustin Spicuzza <dustin@virtualroadside.com>
Just like with other Git commands, this option makes it read the paths
from the standard input. It comes in handy when resetting many, many
paths at once and wildcards are not an option (e.g. when the paths are
generated by a tool).
Note: we first parse the entire list and perform the actual reset action
only in a second phase. Not only does this make things simpler, it also
helps performance, as do_diff_cache() traverses the index and the
(sorted) pathspecs in simultaneously to avoid unnecessary lookups.
This feature is marked experimental because it is still under review in
the upstream Git project.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is a brown paper bag. When adding the tests, we actually failed
to verify that the config variable is heeded in git-init at all. And
when changing the original patch that marked the .git/ directory as
hidden after reading the config, it was lost on this developer that
the new code would use the hide_dotfiles variable before the config
was read.
The fix is obvious: read the (limited, pre-init) config *before*
creating the .git/ directory.
This fixes https://github.com/git-for-windows/git/issues/789
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In preparation for rebasing onto v2.21.0-rc, this janitorial
merging-rebase juggles a few things around and updates others:
- The `case-insensitive-abspath`, `unc-path-w-backslashes`,
`azure-pipelines` and `stash-in-c` branches were updated to reflect
the versions that made it into v2.21.0-rc0.
- As the patch in `kraai/2006` was folded into `stash-in-c` upstream, we
did the same here.
- The branches `status-no-lock-index` and
`phase-out-show-ignored-directory-gracefully`, intended to help with
phasing out two Git for Windows-only features (that made it into core
Git in different forms), were moved to the bottom of the branch
thicket.
- The `funny-cased-cwd`, `remove-ipv6-fallback`, `open-in-gdb`,
`mingw-build-options-fix`, `http-version`, `builtin-rebase-perf-fix`,
`test-oid-fix-windows` and `external-diff-save-env`
patches were moved into the `ready-for-upstream` thicket.
- The `rebase-post-checkout-hook` and the `builtin-rebase--am` branch
was updated to the version that made it into v2.21.0-rc0, and moved to
the `ready-for-upstream` thicket.
- The FSCache-related topics were moved closer together.
- The commit message of `MinGW: Use MakeMaker to build the Perl
libraries` was changed to reflect the fact that we do not even use
MakeMaker anymore.
- The patch `Tests: optionally skip redirecting stdin/stdout/stderr` was
dropped, as the `debug` function learned to un-redirect the streams.
- The commit message of `Skip t9020 with MSys2`, `t9116: work around
hard-to-debug hangs` and `t9001: work around hard-to-debug hangs` were
improved to be a lot more informative, the latter two were also
combined into a single patch.
- The patch `mingw: support spawning programs containing spaces in their
names` was augmented with a regression test, and the commit message
now mentions that this is needed for older Windows versions.
This commit starts the rebase of 4c87c4e2e3 to 7a95a1cd08
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The NtQueryDirectoryFile() call works best (and on Windows 8.1 and
earlier, it works *only*) with buffer sizes up to 64kB. Which is 32k
wide characters, so let's use that as our buffer size.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The fact that Git's test suite is implemented in Unix shell script that
is as portable as we can muster, combined with the fact that Unix shell
scripting is foreign to Windows (and therefore has to be emulated),
results in pretty abysmal speed of the test suite on that platform, for
pretty much no other reason than that language choice.
For comparison: while the Linux build & test is typically done within
about 8 minutes, the Windows build & test typically lasts about 80
minutes in Azure Pipelines.
To help with that, let's use the Azure Pipeline feature where you can
parallelize jobs, make jobs depend on each other, and pass artifacts
between them.
The tests are distributed using the following heuristic: listing all
test scripts ordered by size in descending order (as a cheap way to
estimate the overall run time), every Nth script is run (where N is the
total number of parallel jobs), starting at the index corresponding to
the parallel job. This slicing is performed by a new function that is
added to the `test-tool`.
To optimize the overall runtime of the entire Pipeline, we need to move
the Windows jobs to the beginning (otherwise there would be a very
decent chance for the Pipeline to be run only the Windows build, while
all the parallel Windows test jobs wait for this single one).
We use Azure Pipelines Artifacts for both the minimal Git for Windows
SDK as well as the built executables, as deduplication and caching close
to the agents makes that really fast. For comparison: while downloading
and unpacking the minimal Git for Windows SDK via PowerShell takes only
one minute (down from anywhere between 2.5 to 7 when using a shallow
clone), uploading it as Pipeline Artifact takes less than 30s and
downloading and unpacking less than 20s (sometimes even as little as
only twelve seconds).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Let's use the new `test-tool path-utils file-size` command in the new
JUnit XML feature.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It is a bit ridiculous to spin up a full-blown Perl instance (especially
on Windows, where that means spinning up a full POSIX emulation layer,
AKA the MSYS2 runtime) just to tell how large a given file is.
So let's just use the test-tool to do that job instead.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Make sure to write the .xml in UTF-8 encoding.
We also need to make sure that invalid UTF-8 encoding is turned into
valid UTF-8 (using the Replacement Character, \uFFFD) because t9902's
trace contains such invalid byte sequences, and the task that uploads
the test results would refuse to do anything if it was asked to parse an
.xml file with invalid UTF-8 in it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
While working on parallelizing the tests in Azure Pipelines, an issue
was discovered with the `is_msys2_sh()` function: it expects the path
components to be separated by exactly one dir separator. That does not
need to be the case, though, e.g. when the components in the `PATH`
variable have trailing slashes.
Let's make the code much more robust in this respect.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Every once in a while, the Azure Pipeline fails with some semi-random
error: timer thread did not terminate timely
This error message means that the thread that is used to emulate the
setitimer() function did not terminate within 1,000 milliseconds.
The most likely explanation (and therefore the one we should assume to
be true, according to Occam's Razor) is that the timeout of one second
is simply not enough because we try to run so many tasks in parallel.
So let's give it ten seconds instead of only one. That should be enough.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Instead of a shallow fetch followed by a sparse checkout, we are
better off by using a separate, dedicated Pipeline that bundles
the SDK as a build artifact, and then consuming that build artifact
here.
In fact, since this artifact will be used a lot, we spent substantial
time on figuring out a minimal subset of the Git for Windows SDK, just
enough to build and test Git. The result is a size reduction from around
1GB (compressed) to around 55MB (compressed). This also comes with the
change where we now call `usr\bin\bash.exe` directly, as `git-cmd.exe`
is not included in the minimal SDK.
That reduces the time to initialize Git for Windows' SDK from anywhere
between 2m30s-7m to a little over 1m.
Note: in theory, we could also use the DownloadBuildArtifacts@0 task
here. However, restricted permissions that are in effect when building
from forks would let this fail for PR builds, defeating the whole
purpose of the Azure Pipelines support for git.git.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The Windows job currently takes a whopping ~1h20m to complete. Which is
*far* longer than the next-longest job takes (linux-gcc, ~35m). As such,
it makes sense to start the Windows job first, to minimize the overall
run time (which is now pretty safely the run time of the Windows job).
This affects only the Azure Pipelines configuration, not the Travis one,
of course, as Travis cannot run our Windows job: 1h20m is distinctly
longer than the 50 minute timeout of Travis' free tier.
This commit is best viewed with `--color-moved`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It is not strictly necessary to start a command in PowerShell with `&`,
but it is safer.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Some improvements (suggested via review on the Git mailing list) have
not been incorporated into Git for Windows' `master` yet, other changes
were left-overs from debugging that need reverting.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
At some point we switched from Hosted Linux Preview to Ubuntu 16.04, at
which point it became unnecessary to install the `docker` package for
the Linux-32 job.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
For some reason, the indentation of the PowerShell tasks got all messed
up. Fix that.
While at it, do not define `c()` for only one user, and do not
initialize `/etc/passwd` (it does not seem to have a noticeable effect).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
TASKDEFINITIONSURI is not set in parallel tasks... And COLLECTIONURI is
not set in the Linux32 job...
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
According to getenv(3)'s notes:
The implementation of getenv() is not required to be reentrant. The
string pointed to by the return value of getenv() may be statically
allocated, and can be modified by a subsequent call to getenv(),
putenv(3), setenv(3), or unsetenv(3).
Since strings returned by getenv() are allowed to change on subsequent
calls to getenv(), make sure to duplicate when caching external_diff_cmd
from environment.
This problem becomes apparent on Git for Windows since fe21c6b285
(mingw: reencode environment variables on the fly (UTF-16 <-> UTF-8)),
when the getenv() implementation provided in compat/mingw.c was changed
to keep a certain amount of alloc'ed strings and freeing them on
subsequent calls.
This fixes https://github.com/git-for-windows/git/issues/2007:
$ yes n | git -c difftool.prompt=yes difftool fe21c6b285 fe21c6b285df~100
Viewing (1/404): '.gitignore'
Launch 'bc3' [Y/n]?
Viewing (2/404): 'Documentation/.gitignore'
Launch 'bc3' [Y/n]?
Viewing (3/404): 'Documentation/Makefile'
Launch 'bc3' [Y/n]?
Viewing (4/404): 'Documentation/RelNotes/2.14.5.txt'
Launch 'bc3' [Y/n]?
Viewing (5/404): 'Documentation/RelNotes/2.15.3.txt'
Launch 'bc3' [Y/n]?
Viewing (6/404): 'Documentation/RelNotes/2.16.5.txt'
Launch 'bc3' [Y/n]?
Viewing (7/404): 'Documentation/RelNotes/2.17.2.txt'
Launch 'bc3' [Y/n]?
Viewing (8/404): 'Documentation/RelNotes/2.18.1.txt'
Launch 'bc3' [Y/n]?
Viewing (9/404): 'Documentation/RelNotes/2.19.0.txt'
Launch 'bc3' [Y/n]? error: cannot spawn ¦?: No such file or directory
fatal: external diff died, stopping at Documentation/RelNotes/2.19.1.txt
Signed-off-by: Kim Gybels <kgybels@infogroep.be>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If reset_tree returns a non-zero value, stash_working_tree calls
object_array_clear with &rev.pending before rev is initialized. This
causes a segmentation fault. Prevent this by initializing rev before
calling reset_tree.
This fixes#2006.
Signed-off-by: Matthew Kraai <mkraai@its.jnj.com>
This is what the legacy (scripted) rebase does in
`move_to_original_branch`, and we will need this functionality in the
next commit.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The new test_oid machinery in the test library requires reading
some information from t/oid-info/hash-info and t/oid-info/oid.
The shell logic that reads from these files is sensitive to CRLF
line endings, causing a failure when the test suite is run on a
Windows machine that converts LF to CRLF: the test suite fails
with a "bad hash algorithm" message, but does not record any
failed test cases. This caused CI builds to pass because they
fail only after reporting the failed test cases.
Exclude the files in this folder from this conversion.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
