Wed, 22 Feb 2023 10:09:21 +0100

Describe Git for Windows' architecture (#4286)

The Git for Windows project has grown quite complex over the years,
certainly much more complex than during the first years where the
msysgit.git repository was abusing Git for package management purposes
and the git/git fork was called 4msysgit.git.

Let's describe the status quo in a thorough way.

Tue, 14 Feb 2023 13:19:10 -0500

Merge pull request from GHSA-wxwv-49qw-35pm

Safe path lookup in gitk on windows

Sat, 11 Feb 2023 20:04:20 +0100

git-artifacts: remove workflow (#4282)

Now that this pipeline (including various improvments) has been migrated
to the git-for-windows-automation repo, we can remove it from the main
repo.

Ref:
https://github.com/git-for-windows/git-for-windows-automation/commit/35dbd8da8238774aebfd743f219a95c2c0de9bee

Tue, 31 Jan 2023 17:10:28 +0000

Skip linking the "dashed" `git-<command>`s for built-ins (#4252)

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.

This addresses the concern raised in
https://github.com/git-for-windows/git/pull/4185#discussion_r1051661894

Sat, 28 Jan 2023 07:18:27 +0000

prerelease-2.39.1.windows.1-529-g10a93f8bfd-20230128072130

Fix Windows-specific problem to determine the real path near a drive …

Tue, 24 Jan 2023 11:50:20 +0100

Merge 'readme' into HEAD

Add a README.md for GitHub goodness.

Signed-off-by: Johannes Schindelin <[email protected]>

Tue, 24 Jan 2023 11:50:20 +0100

Merge 'readme' into HEAD

Add a README.md for GitHub goodness.

Signed-off-by: Johannes Schindelin <[email protected]>

Tue, 17 Jan 2023 13:47:49 -0500

Merge v2.39.1.windows.1 (#4219)

This PR takes the embargoed release tag `v2.39.1.windows.1` and merges
it into the `main` branch.

It likely that I messed something up in the order of releasing the
security release and merging the [security
advisory](https://github.com/git-for-windows/git/security/advisories/GHSA-v4px-mx59-w99c).

Thu, 12 Jan 2023 08:26:22 +0000

Update mimalloc to v2.0.9 (#4211)

I recently [upstreamed the mimalloc fixes we developed in Git for
Windows](https://github.com/microsoft/mimalloc/pull/654), most notably
the [fix for running in Windows Nano
Server](https://github.com/git-for-windows/git/pull/4074). In the
meantime, that PR was accepted and a new version was created from it
(that also includes a couple of other fixes). Let's integrate the latest
version.

Wed, 21 Dec 2022 14:21:29 +0100

amend! mimalloc: offer a build-time option to enable it

mimalloc: offer a build-time option to enable it

By defining `USE_MIMALLOC`, Git can now be compiled with that
nicely-fast and small allocator.

Note that we have to disable a couple `DEVELOPER` options to build
mimalloc's source code, as it makes heavy use of declarations after
statements, among other things that disagree with Git's conventions.

We even have to silence some GCC warnings in non-DEVELOPER mode. For
example, the `-Wno-array-bounds` flag is needed because in `-O2` builds,
trying to call `NtCurrentTeb()` (which `_mi_thread_id()` does on
Windows) causes the bogus warning about a system header, likely related
to https://sourceforge.net/p/mingw-w64/mailman/message/37674519/ and to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578:

C:/git-sdk-64-minimal/mingw64/include/psdk_inc/intrin-impl.h:838:1:
        error: array subscript 0 is outside array bounds of 'long long unsigned int[0]' [-Werror=array-bounds]
  838 | __buildreadseg(__readgsqword, unsigned __int64, "gs", "q")
      | ^~~~~~~~~~~~~~

Also: The `mimalloc` library uses C11-style atomics, therefore we must
require that standard when compiling with GCC if we want to use
`mimalloc` (instead of requiring "only" C99). This is what we do in the
CMake definition already, therefore this commit does not need to touch
`contrib/buildsystems/`.

Signed-off-by: Johannes Schindelin <[email protected]>