Windows build switches from MINGW64 to URCR64 runtime starting Git
2.56.0; switch the cmake based build at the same time.
* js/win-cmake-use-ucrt64:
cmake(windows): accommodate for Git for Windows' migration to UCRT64
Correct tests that depend on Perl running on MinGW
* js/mingw-test-fixes-around-perl:
t9129: skip UTF-8 tests on Windows
t9700: accommodate for MSYS2 Perl reporting as `cygwin`
The git rev-list command has been augmented with a '--missing-only'
option that filters the output to only show missing objects,
stripping the leading '?' character and suppressing present objects,
which is useful when used in combination with '--missing=print' or
'--missing=print-info'.
* sa/rev-list-missing-only:
rev-list: add --missing-only option to filter output
"git maintenance" triggered "rerere gc" in unappropriate times and
interfered with "git rebase" etc. too much. The conditions "rerere
gc" gets triggered have been tweaked.
* ps/tune-rerere-gc:
builtin/maintenance: improve heuristic for "rerere gc"
rerere: extract logic to determine whether entries are stale
The autostash fallback in 'git checkout -m' has been refined to only
retry when there are local changes. Additionally, a blank line now
visually separates autostash conflict advice from the subsequent
branch-switch message.
* hn/checkout-m-autostash-refine:
checkout: separate autostash conflict advice from branch-switch message
stash: reserve exit status 1 for conflicts
The 'git imap-send' command has been taught to take the '--draft'
option to mark uploaded messages as drafts, which helps some email
clients render them properly for editing and sending.
* wf/imap-send-draft:
imap-send: add --draft to set IMAP \Draft flag
CGI helper scripts used by HTTP-related test scripts have been updated
to use atomic filesystem operations, preventing race conditions when
Apache handles concurrent requests.
* mm/lib-httpd-cgi-safe:
t/lib-httpd: document writing concurrency-safe CGI helpers
t/lib-httpd: make http-429 first-request check atomic
t/lib-httpd: fix apply-one-time-script race under concurrent requests
The development helper script to lint gitlink references in the
documentation has been updated to avoid a newer Perl regular
expression syntax that breaks on older Perl versions.
* ta/lint-gitlink-older-perl-fix:
lint-gitlink: don't use empty lower bound in .{0,8}
Running "git history" in a corrupt repository can (unsurprisingly)
segfault when a necessary tree object is not found.
* jc/history-missing-tree-errorfix:
history: do not dereference NULL when parent tree is missing
The documentation for 'git cherry-pick' has been updated to clarify
that the '--no-commit' option intentionally skips setting the
'CHERRY_PICK_HEAD' ref. A test has also been added to ensure this
behavior holds even when the operation stops for conflicts.
* as/cherry-pick-no-commit-doc:
doc: cherry-pick: note --no-commit skips CHERRY_PICK_HEAD
t3507: check no CHERRY_PICK_HEAD after conflicting --no-commit
The gitdatamodel documentation page has been linked from a handful
of key documentaiton pages.
* kh/doc-datamodel:
doc: datamodel: link to the glossary
doc: glossary: link four of the terms to gitdatamodel(7)
doc: git: link to the gitdatamodel(7) tutorial
doc: git: list gitdatamodel(7) as a concept guide
The process of downloading packfile URIs in protocol v2 has been
instrumented with a Trace2 region. This visibility allows tracking
the cumulative time spent downloading external packs and the number
of advertised URIs without emitting a separate event per pack.
* tn/fetch-pack-trace-packfile-uri:
fetch-pack: trace packfile URI downloads
Two members in "struct pathspec_item" were of type "char *", but
nobody updated the string through these pointers. They have been
made "const char *" instead.
* jc/pathspec-match-const:
pathspec: match and original in pathspec_item are const
The error path in 'git submodule--helper' has been updated to plug a
memory leak when a repository handle could not be obtained,
leveraging an updated idempotent repo_clear().
* jk/submodule-error-leak:
submodule--helper: free URL when repository setup fails
repository: make repo_clear() idempotent
Teach 'am', 'revert', and 'rebase' that running 'commit --amend' or a
partial 'commit <paths>' makes no sense during operations that stop
and return control to the user to resolve conflicts left in the
working tree, just like 'cherry-pick' and 'merge' do.
* en/no-amend-during-conflicts:
commit: refuse partial commits during conflict resolution
commit: refuse to amend during conflict resolution
commit: reword the empty-commit rebase amend error
commit: allow a partial commit when a rebase pick becomes empty
commit: clarify FROM_REBASE_PICK and is_from_rebase() names
The CI script to install dependencies for the documentation build
has been updated to install asciidoctor directly via the system
package manager instead of pinning to an older version via gem.
Additionally, an obsolete variable used for retired Azure Pipelines
environments has been removed.
* jk/ci-use-system-asciidoctor:
ci: use system asciidoctor
Git for Windows needs to ship with a lot of Unix tools that Git takes
for granted, such as `sed`, `awk`, a C compiler and a Unix shell, just
to name a few. In Git for Windows, these are provided by the MSYS2
project.
Part of these tools (such as `bash.exe`) use a POSIX emulation layer
("MSYS2 runtime", a friendly fork of the Cygwin runtime), but others
target a native Win32 toolchain, e.g. `git.exe`. There are multiple
flavors of that toolchain, and historically Git for Windows used MINGW64
on x64 Windows. This toolchain uses the old MSVC runtime, and therefore
the MSYS2 project deprecated it.
As a consequence, Git for Windows switches to UCRT64 with v2.56.0. That
flavor still uses GCC to compile native Win32 binaries, but targets the
Universal C Runtime ("UCRT"). Internally, this means that the new
`git.exe` is installed into a new prefix, `/ucrt64/`, whereas the old
`git.exe` was installed into `/mingw64/`.
A recently-upstreamed commit hard-codes this expectation even into the
CMake-based build, so that the built `git.exe` "knows where it lives"
and can ensure that the tools it expects on the `PATH` are found.
Naturally, this hard-coded MINGW64 needs to change to UCRT64 now, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The assumption of this test is that Perl and Git have the same idea how
to perform encoding conversions.
However, in Git for Windows, Git is a native Win32 program, and such
programs have a very different concept of encodings (called "Code
Pages", and they are not controlled via environment variables at all),
whereas the Perl interpreter used in Git for Windows is a pseudo-Unix
one that uses the MSYS2 runtime (which _does_ try very much to abide by
Unix' `LC_ALL` and friends, and totally ignores Windows' current or
active code pages).
As such, these test cases _cannot_ work with Git for Windows. So let's
just skip them on that platform.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As of a year or two ago, there is this push to align MSYS2 more closely
with Cygwin, so as to benefit from a closer collaboration. Part of that
is that the triplet `x86_64-pc-cygwin` is used nowadays, whereas it had
been `x86_64-pc-msys` previously. Likewise, Perl now reports `$^O` as
`cygwin` instead of `msys`.
The Perl module test used `msys` as tell-tale when to accommodate for a
native Windows version of `git.exe` which would report absolute
_Windows_ paths rather than those pseudo-Unix paths. We cannot use that
tell-tale anymore, and we also cannot adjust it to `cygwin` because that
would break in Cygwin (where `git.exe` reports absolute pseudo-Unix
paths).
Let's use the environment variable `MSYSTEM` instead (being mindful that
the `MSYSTEM=MSYS` variant would _also_ reflect a setup where `git.exe`
won't report absolute _Windows_ paths).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Our CI Documentation builds have pinned asciidoctor since 615a6c37e1
(ci: stick with Asciidoctor v1.5.8 for now, 2019-03-29). Back then a few
changes were needed to build with the then-new v2.0.0.
We've since made those changes, in f6461b82b9 (Documentation: fix build
with Asciidoctor 2, 2019-09-15) and other commits. So it is not only
safe to use newer versions of asciidoctor, but preferable: it's what
people are likely to use for actually building the documentation in
practice!
I don't think there's any need to pin to a specific version. We can just
use what ships in our Ubuntu image, which should give us an arbitrary
representative version (and if it changes and something breaks, we'd
want to know).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A collection of patches from Git for Windows has been upstreamed,
mostly focusing on simplifying and robustifying build configurations
for MinGW/MSYS2, dropping obsolete compatibility options, and allowing
the main 'git.exe' to be used directly without the extra wrapper
process on Windows.
* js/mingw-build-updates:
t0060: adjust the code style
mingw: allow `git.exe` to be used instead of the "Git wrapper"
mingw: ensure valid CTYPE
mingw: always define `ETC_*` for MSYS2 environments
windows: skip linking `git-<command>` for built-ins
mingw: rely on MSYS2's metadata instead of hard-coding it
mingw: only enable the MSYS2-specific stuff when compiling in MSYS2
mingw: set the prefix and HOST_CPU as per MSYS2's settings
mingw: avoid over-specifying `--pic-executable`
mingw: only use -Wl,--large-address-aware for 32-bit builds
mingw: drop the -D_USE_32BIT_TIME_T option
mingw: stop hard-coding `CC = gcc`
mingw: include the Python parts in the build
The CI script to install dependencies for the documentation build
has been updated to install asciidoctor directly via the system
package manager instead of pinning to an older version via gem.
Additionally, an obsolete variable used for retired Azure Pipelines
environments has been removed.
* jk/ci-use-system-asciidoctor:
ci: drop ALREADY_HAVE_ASCIIDOCTOR variable
ci: fix missing Ruby dependency in "documentation" job
The CI job for Debian 11 has been updated to use Debian 12, as the
former is now out of the LTS period.
* jk/ci-bump-debian-to-12:
ci: bump debian-11 job to debian-12
* 'master' of https://github.com/j6t/gitk:
gitk: discourage AI contributions
gitk: move UI for generic colors above diff colors
gitk: avoid constructing dialog titles from text pieces
gitk: use more natural language for labels of color preferences
gitk: show color preferences on the button instead of the label
gitk: condense repetitive code around color buttons into foreach loops
gitk: set intitial colors of swatches using the available helper
Our install-dependencies script avoids installing asciidoctor if the
CI environment claims to have it already. But the only environment which
made use of this was Azure Pipelines, which went away in 6081d3898f (ci:
retire the Azure Pipelines definition, 2020-04-11). So this conditional
was effectively doing nothing. Let's clean it up.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Our "documentation" job has recently stopped working with the following
error:
+ sudo gem install --version 1.5.8 asciidoctor
+ gem install --version 1.5.8 asciidoctor
./ci/install-dependencies.sh: 23: gem: not found
The root cause of this is that we never explicitly install Ruby, and
consequently gem(1) isn't explicitly pulled in, either. This used to
work alright because we transitively pulled in Ruby via asciidoc. But
due to an update it seems that we stopped pulling in the transitive
dependency, and consequently we don't have gem(1) available anymore.
Fix this by explicitly installing Ruby.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix conjoined bullet items for the maintenance strategies in
git-config(1). Reportedly, asciidoctor renders this document correctly
both before and after this patch. asciidoc renders it correctly only
_after_ this patch.
Signed-off-by: Brigham Campbell <me@brighamcampbell.com>
Acked-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The object lookup machinery has been taught to gracefully recover
when a multi-pack-index points to an owning pack that was removed
during a concurrent geometric repack, and 'git replay' has been
fixed to not segfault when reading such missing objects.
* en/midx-missing-pack-fallback:
packfile: recover when a multi-pack-index names a removed pack
mktree: do not use OBJECT_INFO_QUICK when checking objects
mktree: plug per-tree leak in --batch mode
replay: fail gracefully when a merge input is unreadable
The memory ownership of argv elements passed to the revision
machinery has been made more robust by keeping logically "freed"
elements alive until the rev_info struct is released, preventing
use-after-free bugs when options store references to them.
* jk/rev-info-argv-to-free:
revision: simplify mark_argv_for_free() callers
revision: hang on to "freed" argv elements
The 'git replay' command has been taught the '--linearize' option to
drop merge commits and linearize the replayed history, mimicking 'git
rebase --no-rebase-merges'.
* tc/replay-linearize:
replay: offer an option to linearize the commit topology
replay: resolve the replay base outside pick_regular_commit()
replay: add helper to put entry into replayed_commits
Various spelling mistakes in comments and test descriptions have
been corrected.
* hk/typofix:
versioncmp: fix typo in versioncmp.c, t/t0022-crlf-rename.sh
The string extraction logic for the branch name and worktree name
from the given path in 'git worktree add' has been corrected and
simplified to avoid out-of-bounds reads and improper handling of
trailing slashes.
* rs/worktree-add-basename-fixes:
worktree add: let worktree_basename() return string copy
worktree add: trim slashes when deriving branch name from path
worktree add: reject separator-only path
worktree add: don't read out of bounds in worktree_basename()
GitHub Actions CI workflow runs triggered by pull requests have
been configured to cancel older runs when a new push is made to the
same pull request.
* hn/ci-cancel-stale-pr-runs:
ci: cancel stale pull request workflow runs
A few tests for the reference handling subsystem have been added to
exercise the handling of forbidden characters and symbolic references.
* ns/ref-symref-additional-tests:
t1402: test forbidden characters in refnames
t1401: check symbolic-ref failure and --quiet silence on a non-symbolic ref
These days, the test cases are less free-form than in the wild old days
of the Git project.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git for Windows wants to add `git.exe` to the users' `PATH`, without
cluttering the latter with unnecessary executables such as `wish.exe`.
To that end, it invented the concept of its "Git wrapper", i.e. a tiny
executable located in `C:\Program Files\Git\cmd\git.exe` (originally a
CMD script) whose sole purpose is to set up a couple of environment
variables and then spawn the _actual_ `git.exe` (which nowadays lives in
`C:\Program Files\Git\mingw64\bin\git.exe` for 64-bit, and the obvious
equivalent for 32-bit installations).
Currently, the following environment variables are set unless already
initialized:
- `MSYSTEM`, to make sure that the MSYS2 Bash and the MSYS2 Perl
interpreter behave as expected, and
- `PLINK_PROTOCOL`, to force PuTTY's `plink.exe` to use the SSH
protocol instead of Telnet,
- `PATH`, to make sure that the `bin` folder in the user's home
directory, as well as the `/mingw64/bin` and the `/usr/bin`
directories are included. The trick here is that the `/mingw64/bin/`
and `/usr/bin/` directories are relative to the top-level installation
directory of Git for Windows (which the included Bash interprets as
`/`, i.e. as the MSYS pseudo root directory).
Using the absence of `MSYSTEM` as a tell-tale, we can detect in
`git.exe` whether these environment variables have been initialized
properly. Therefore we can call `C:\Program Files\Git\mingw64\bin\git`
in-place after this change, without having to call Git through the Git
wrapper.
Obviously, above-mentioned directories must be _prepended_ to the `PATH`
variable, otherwise we risk picking up executables from unrelated Git
installations. We do that by constructing the new `PATH` value from
scratch, appending `$HOME/bin` (if `HOME` is set), then the MSYS2 system
directories, and then appending the original `PATH`.
Side note: this modification of the `PATH` variable is independent of
the modification necessary to reach the executables and scripts in
`/mingw64/libexec/git-core/`, i.e. the `GIT_EXEC_PATH`. That
modification is still performed by Git, elsewhere, long after making the
changes described above.
While we _still_ cannot simply hard-link `mingw64\bin\git.exe` to `cmd`
(because the former depends on a couple of `.dll` files that are only in
`mingw64\bin`, i.e. calling `...\cmd\git.exe` would fail to load due to
missing dependencies), at least we can now avoid that extra process of
running the Git wrapper (which then has to wait for the spawned
`git.exe` to finish) by calling `...\mingw64\bin\git.exe` directly, via
its absolute path.
Testing this is in Git's test suite tricky: we set up a "new" MSYS
pseudo-root and copy the `git.exe` file into the appropriate location,
then verify that `MSYSTEM` is set properly, and also that the `PATH` is
modified so that scripts can be found in `$HOME/bin`, `/mingw64/bin/`
and `/usr/bin/`.
This addresses https://github.com/git-for-windows/git/issues/2283
Note: This keeps the same, hard-coded MSYSTEM platform support for CMake
as before, and introduces an `msystem' and `mingw-prefix` knob for Meson
(read: neither CMake nor Meson will automatically inherit the setting
from the current build environment).
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A change between versions 2.4.1 and 2.6.0 of the MSYS2 runtime modified
how Cygwin's runtime (and hence Git for Windows' MSYS2 runtime
derivative) handles locales: d16a56306d (Consolidate wctomb/mbtowc calls
for POSIX-1.2008, 2016-07-20).
An unintended side-effect is that "cold-calling" into the POSIX
emulation will start with a locale based on the current code page,
something that Git for Windows is very ill-prepared for, as it expects
to be able to pass a command-line containing non-ASCII characters to the
shell without having those characters munged.
One symptom of this behavior: when `git clone` or `git fetch` shell out
to call `git-upload-pack` with a path that contains non-ASCII
characters, the shell tried to interpret the entire command-line
(including command-line parameters) as executable path, which obviously
must fail.
This fixes https://github.com/git-for-windows/git/issues/1036
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Special-casing even more configurations simply does not make sense.
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is merely a historical wart that, say, `git-commit` exists in the
`libexec/git-core/` directory, a tribute to the original idea to let Git
be essentially a bunch of Unix shell scripts revolving around very few
"plumbing" (AKA low-level) commands.
Git has evolved a lot from there. These days, most of Git's
functionality is contained within the `git` executable, in the form of
"built-in" commands.
To accommodate for scripts that use the "dashed" form of Git commands,
even today, Git provides hard-links that make the `git` executable
available as, say, `git-commit`, just in case that an old script has not
been updated to invoke `git commit`.
Those hard-links do not come cheap: they take about half a minute for
every build of Git on Windows, they are mistaken for taking up huge
amounts of space by some Windows Explorer versions that do not
understand hard-links, and therefore many a "bug" report had to be
addressed.
The "dashed form" has been officially deprecated in Git version 1.5.4,
which was released on February 2nd, 2008, i.e. a very long time ago.
This deprecation was never finalized by skipping these hard-links, but
we can start the process now, in Git for Windows.
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
MSYS2 defines some helpful environment variables, e.g. `MSYSTEM`. There
is code in Git for Windows to ensure that that `MSYSTEM` variable is
set, hard-coding a default.
However, the existing solution jumps through hoops to reconstruct the
proper default, and is even incomplete doing so, as we found out when we
extended it to support CLANGARM64.
This is absolutely unnecessary because there is already a perfectly
valid `MSYSTEM` value we can use at build time. This is even true when
building the MINGW32 variant on a MINGW64 system because `makepkg-mingw`
will override the `MSYSTEM` value as per the `MINGW_ARCH` array.
The same is equally true for the `/mingw64`, `/mingw32` and
`/clangarm64` prefix: those values are already available via the
`MINGW_PREFIX` environment variable, and we just need to pass that
setting through.
Only when `MINGW_PREFIX` is not set (as is the case in Git for Windows'
minimal SDK, where only `MSYSTEM` is guaranteed to be set correctly), we
use as fall-back the top-level directory whose name is the down-cased
value of the `MSYSTEM` variable.
Incidentally, this also broadens the support to all the configurations
supported by the MSYS2 project, i.e. clang64 & ucrt64, too.
Helped-by: Johannes Sixt <j6t@kdbg.org>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The tell-tale is the presence of the `MSYSTEM` value while compiling, of
course. In that case, we want to ensure that `MSYSTEM` is set when
running `git.exe`, and also enable the magic MSYS2 tty detection.
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
MSYS2 already defines a couple of helpful environment variables, and we
can use those to infer the installation location as well as the CPU. No
need for hard-coding ;-)
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In bf2d5d8239e (Don't let ld strip relocations, 2016-01-16) (picked from
https://github.com/git-for-windows/git/pull/612/commits/6a237925bf10),
Git for Windows introduced the `-Wl,-pic-executable` flag, specifying
the exact entry point via `-e`. This required discerning between i686
and x86_64 code because the former required the symbol to be prefixed
with an underscore, the latter did not.
As per https://sourceware.org/bugzilla/show_bug.cgi?id=10865, the
specified symbols are already the default, though.
So let's drop the overly-specific definition.
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
That option only matters there, and is in fact only really understood in
those builds; UCRT64 versions of GCC, for example, do not know what to
do with that option.
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This option was added in fa93bb20d7 (MinGW: Fix stat definitions to
work with MinGW runtime version 4.0, 2013-09-11), i.e. a _long_ time
ago. So long, in fact, that it still targeted MinGW. But we switched to
mingw-w64 in 2015, which seems not to share the problem, and therefore
does not require a fix.
Even worse: This flag is incompatible with UCRT64, which we are about to
support by way of upstreaming `mingw-w64-git` to the MSYS2 project, see
https://github.com/msys2/MINGW-packages/pull/26470 for details.
So let's send that option into its well-deserved retirement.
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano