When user is asked for credentials there is no need to mask username,
so PROMPT_ASKPASS flag on calling credential_ask_one for login is
unnecessary.
credential_ask_one internally uses git_prompt which in case of given
flag PROMPT_ASKPASS uses masked input method instead of
git_terminal_prompt, which does not mask user input.
This fixes#675
Signed-off-by: yaras <yaras6@gmail.com>
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>
Usually we don't need to set libcurl to choose which version of the
HTTP protocol to use to communicate with a server.
But different versions of libcurl, the default value is not the same.
CURL >= 7.62.0: CURL_HTTP_VERSION_2TLS
CURL < 7.62: CURL_HTTP_VERSION_1_1
In order to give users the freedom to control the HTTP version,
we need to add a setting to choose which HTTP version to use.
Signed-off-by: Force Charlie <charlieio@outlook.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
For many Win32 functions, there actually exist two variants: one with
the `A` suffix that takes ANSI parameters (`char *` or `const char *`)
and one with the `W` suffix that takes Unicode parameters (`wchar_t *`
or `const wchar_t *`).
Let's be precise what we want to use.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Using FindFirstFileExW() requires the OS to allocate a 64K buffer for each
directory and then free it when we call FindClose(). Update fscache to call
the underlying kernel API NtQueryDirectoryFile so that we can do the buffer
management ourselves. That allows us to allocate a single buffer for the
lifetime of the cache and reuse it for each directory.
This change improves performance of 'git status' by 18% in a repo with ~200K
files and 30k folders.
Documentation for NtQueryDirectoryFile can be found at:
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntifs/nf-ntifs-ntquerydirectoryfilehttps://docs.microsoft.com/en-us/windows/desktop/FileIO/file-attribute-constantshttps://docs.microsoft.com/en-us/windows/desktop/fileio/reparse-point-tags
To determine if the specified directory is a symbolic link, inspect the
FileAttributes member to see if the FILE_ATTRIBUTE_REPARSE_POINT flag is
set. If so, EaSize will contain the reparse tag (this is a so far
undocumented feature, but confirmed by the NTFS developers). To
determine if the reparse point is a symbolic link (and not some other
form of reparse point), test whether the tag value equals the value
IO_REPARSE_TAG_SYMLINK.
Signed-off-by: Ben Peart <benpeart@microsoft.com>
We cannot rely on `uname -m` in Git for Windows' SDK to tell us what
architecture we are compiling for, as we can compile both 32-bit and
64-bit `git.exe` from a 64-bit SDK, but the `uname -m` in that SDK will
always report `x86_64`.
So let's go back to our original design. And make it explicitly
Windows-specific.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The recent change to make fscache thread specific relied on fscache_enable()
being called first from the primary thread before being called in parallel
from worker threads. Make that more robust and protect it with a critical
section to avoid any issues.
Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Ben Peart <benpeart@microsoft.com>
To support IPv6, Git provided fall back functions for Windows versions that
did not support IPv6. However, as Git dropped support for Windows XP and
prior, those functions are not needed anymore.
Removed those fallbacks by reverting commit[1] and using the functions
directly (without 'ipv6_' prefix).
[1] fe3b2b7b82.
Signed-off-by: tanushree27 <tanushreetumane@gmail.com>
This brings substantial wins in performance because the FSCache is now
per-thread, being merged to the primary thread only at the end, so we do
not have to lock (except while merging).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When debugging Git, the criss-cross spawning of processes can make
things quite a bit difficult, especially when a Unix shell script is
thrown in the mix that calls a `git.exe` that then segfaults.
To help debugging such things, we introduce the `open_in_gdb()` function
which can be called at a code location where the segfault happens (or as
close as one can get); This will open a new MinTTY window with a GDB
that already attached to the current process.
Inspired by Derrick Stolee.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Now that the fscache is single threaded, take advantage of the mem_pool as
the allocator to significantly reduce the cost of allocations and frees.
With the reduced cost of free, in future patches, we can start freeing the
fscache at the end of commands instead of just leaking it.
Signed-off-by: Ben Peart <benpeart@microsoft.com>
