Our breaking changes document says that we'll enable Rust by default in
Git 2.54. Adjust the Makefile to switch the option from WITH_RUST to
NO_RUST to enable it by default and update the help text accordingly.
Similarly, for Meson, enable the option by default and do not
automatically disable it if Cargo is missing, since the goal is to help
users find where they are likely to have problems in the future.
Update our CI tests to swap out the single Linux job with Rust to a
single job without, both for Makefile and Meson. Similarly, update the
Windows Makefile job to not use Rust, while the Meson job (which does
not build with ci/lib.sh) will default to having it enabled.
Move the check for Cargo in the Meson build because it is no longer
needed in the main script.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Older versions of Rust on Linux, such as that used in Debian 11 in our
CI, require linking against libdl. Were we linking with Cargo, this
would be included automatically, but since we're not, explicitly set it
in the system-specific config.
This library is part of libc, so linking against it if it happens to be
unnecessary will add no dependencies to the resulting binary. In
addition, it is provided by both glibc and musl, so it should be
portable to almost all Linux systems.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We missed the cut-off for Rust by default in 2.53, but we still can
enable it by default for 2.54, so update our breaking changes document
accordingly.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git ls-remote '+refs/tags/*:refs/tags/*' https://..." run outside a
repository would dereference a NULL while trying to see if the given
refspec is a single-object refspec, which has been corrected.
* kj/refspec-parsing-outside-repository:
refspec: fix typo in comment
remote-curl: fall back to default hash outside repo
Junio C Hamano [Wed, 1 Apr 2026 17:28:19 +0000 (10:28 -0700)]
Merge branch 'jk/t0061-bat-test-update'
A test to run a .bat file with whitespaces in the name with arguments
with whitespaces in them was flaky in that sometimes it got killed
before it produced expected side effects, which has been rewritten to
make it more robust.
* jk/t0061-bat-test-update:
t0061: simplify .bat test
Junio C Hamano [Wed, 1 Apr 2026 17:28:18 +0000 (10:28 -0700)]
Merge branch 'jk/diff-highlight-more'
Various updates to contrib/diff-highlight, including documentation
updates, test improvements, and color configuration handling.
* jk/diff-highlight-more:
diff-highlight: fetch all config with one process
diff-highlight: allow module callers to pass in color config
diff-highlight: test color config
diff-highlight: use test_decode_color in tests
t: add matching negative attributes to test_decode_color
diff-highlight: check diff-highlight exit status in tests
diff-highlight: drop perl version dependency back to 5.8
diff-highlight: mention build instructions
Junio C Hamano [Mon, 30 Mar 2026 20:57:02 +0000 (13:57 -0700)]
Merge branch 'jw/object-name-bitset-to-enum'
The unsigned integer that is used as an bitset to specify the kind
of branches interpret_branch_name() function has been changed to
use a dedicated enum type.
* jw/object-name-bitset-to-enum:
object-name: turn INTERPRET_BRANCH_* constants into enum values
Junio C Hamano [Mon, 30 Mar 2026 20:57:00 +0000 (13:57 -0700)]
Merge branch 'jw/apply-corrupt-location'
"git apply" now reports the name of the input file along with the
line number when it encounters a corrupt patch, and correctly
resets the line counter when processing multiple patch files.
* jw/apply-corrupt-location:
apply: report input location in binary and garbage patch errors
apply: report input location in header parsing errors
apply: report the location of corrupt patches
Junio C Hamano [Fri, 27 Mar 2026 18:00:02 +0000 (11:00 -0700)]
Merge branch 'kh/doc-interpret-trailers-1'
Doc updates.
* kh/doc-interpret-trailers-1:
interpret-trailers: use placeholder instead of *
doc: config: convert trailers section to synopsis style
doc: interpret-trailers: normalize and fill out options
doc: interpret-trailers: convert to synopsis style
Junio C Hamano [Mon, 23 Mar 2026 16:54:42 +0000 (09:54 -0700)]
regexp: leave a pointer to resurrect workaround for Homebrew
Recently some GitHub CI jobs were broken by update on the platform
side, which was eventually resolved by image rollback, but in the
meantime Dscho invented a workaround patch to sidestep the broken
part of the platform. Their future image update may contain the
same bug, in which case the workaround may again become needed.
As we do not want to be building with workaround that avoids system
regexp library altogether unless the system is known to be broken,
so short of an automated "detect broken system and apply workaround"
mechanism, let's use the folks who are compiling the code to detect
breakage on their system and cope with the breakage ;-)
Jeff King [Wed, 25 Mar 2026 06:13:57 +0000 (02:13 -0400)]
t0061: simplify .bat test
The test added by 71f4960b91 (t0061: fix test for argv[0] with spaces
(MINGW only), 2019-10-01) checks that we can use a .bat file with spaces
as GIT_SSH.
This is a good test in the sense that it's how the original bug was
detected. And as the commit message there describes, there are some
elements of the bug that are likely to come up with GIT_SSH and not
elsewhere: namely that in addition to the .bat file having spaces, we
must pass an argument with spaces (which happens naturally with ssh,
since we pass the upload-pack shell command for the other side to run).
But using GIT_SSH does complicate matters:
1. We actually run the ssh command _twice_, once to probe the ssh
variant with "-G" in fill_ssh_args(), and then a second time to
actually make the connection. So we have to account for that when
checking the output.
2. Our fake ssh .bat file does not actually run ssh. So we expect the
command to fail, but not before the .bat file has touched the "out"
marker file that tells us it has run.
This works now, but is fragile. In particular, the .bat file by
default will echo commands it runs to stdout. From the perspective
of the parent Git process, this is protocol-breaking garbage, and
upon seeing it will die().
That is OK for now because we don't bother to do any cleanup of the
child process. But there is a patch under discussion, dd3693eb08
(transport-helper, connect: use clean_on_exit to reap children on
abnormal exit, 2026-03-12), which causes us to kill() the .bat
process. This happens before it actually touches the "out" file,
causing the test to fail.
We can simplify this by just using the "test-tool run-command" helper.
That lets us run whatever command we like with the arguments we want.
The argument here has a space, which is enough to trigger the original
bug that 71f4960b91 was testing. I verified that by reverting eb7c786314
(mingw: support spawning programs containing spaces in their names,
2019-07-16), the original fix, and confirming that the test fails (but
succeeds without the revert).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Tue, 24 Mar 2026 19:31:34 +0000 (12:31 -0700)]
Merge branch 'ps/upload-pack-buffer-more-writes'
Reduce system overhead "git upload-pack" spends on relaying "git
pack-objects" output to the "git fetch" running on the other end of
the connection.
* ps/upload-pack-buffer-more-writes:
builtin/pack-objects: reduce lock contention when writing packfile data
csum-file: drop `hashfd_throughput()`
csum-file: introduce `hashfd_ext()`
sideband: use writev(3p) to send pktlines
wrapper: introduce writev(3p) wrappers
compat/posix: introduce writev(3p) wrapper
upload-pack: reduce lock contention when writing packfile data
upload-pack: prefer flushing data over sending keepalive
upload-pack: adapt keepalives based on buffering
upload-pack: fix debug statement when flushing packfile data
Junio C Hamano [Tue, 24 Mar 2026 19:31:32 +0000 (12:31 -0700)]
Merge branch 'ps/history-split'
"git history" learned the "split" subcommand.
* ps/history-split:
builtin/history: implement "split" subcommand
builtin/history: split out extended function to create commits
cache-tree: allow writing in-memory index as tree
add-patch: allow disabling editing of hunks
add-patch: add support for in-memory index patching
add-patch: remove dependency on "add-interactive" subsystem
add-patch: split out `struct interactive_options`
add-patch: split out header from "add-interactive.h"
Junio C Hamano [Tue, 24 Mar 2026 19:26:58 +0000 (12:26 -0700)]
use strvec_pushv() to add another strvec
Add and apply a semantic patch that simplifies the code by letting
strvec_pushv() append the items of a second strvec instead of pushing
them one by one.
Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
K Jayatheerth [Tue, 24 Mar 2026 01:57:33 +0000 (07:27 +0530)]
remote-curl: fall back to default hash outside repo
When a remote helper like git-remote-http is invoked outside of a
repository (for example, by running git ls-remote in a non-git
directory), setup_git_directory_gently() leaves the_hash_algo
uninitialized as NULL.
If the user has a globally configured fetch refspec, remote-curl
attempts to parse it during initialization. Inside parse_refspec(),
it checks whether the LHS of the refspec is an exact OID by evaluating
llen == the_hash_algo->hexsz. Because the_hash_algo is NULL, this
results in a segmentation fault.
In 9e89dcb66a (builtin/ls-remote: fall back to SHA1 outside of a repo,
2024-08-02), we added a workaround to ls-remote to fall back to the
default hash algorithm to prevent exactly this type of crash when
parsing refspec capabilities. However, because remote-curl runs as a
separate process, it does not inherit that fallback and crashes anyway.
Instead of pushing a NULL-guard workaround down into parse_refspec(),
fix this by mirroring the ls-remote workaround directly in
remote-curl.c. If we are operating outside a repository, initialize
the_hash_algo to GIT_HASH_DEFAULT. This keeps the HTTP transport
consistent with non-HTTP transports that execute in-process, preventing
crashes without altering the generic refspec parsing logic.
Reported-by: Jo Liss <joliss@gmail.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Mon, 23 Mar 2026 16:20:31 +0000 (09:20 -0700)]
Merge branch 'bb/imap-send-openssl-4.0-prep'
"imap-send" used to use functions whose use is going to be removed
with OpenSSL 4.0; rewrite them using public API that has been
available since OpenSSL 1.1 since 2016 or so.
* bb/imap-send-openssl-4.0-prep:
imap-send: move common code into function host_matches()
imap-send: use the OpenSSL API to access the subject common name
imap-send: use the OpenSSL API to access the subject alternative names
Jeff King [Mon, 23 Mar 2026 06:02:18 +0000 (02:02 -0400)]
diff-highlight: fetch all config with one process
When diff-highlight was written, there was no way to fetch multiple
config keys _and_ have them interpreted as colors. So we were stuck
with either invoking git-config once for each config key, or fetching
them all and converting human-readable color names into ANSI codes
ourselves.
I chose the former, but it means that diff-highlight kicks off 6
git-config processes (even if you haven't configured anything, it has to
check each one).
Note that any callers which pass in colors directly to the module via
@OLD_HIGHLIGHT and @NEW_HIGHLIGHT (like diff-so-fancy plans to do) are
unaffected; those colors suppress any config lookup we'd do ourselves.
You can see the effect like:
# diff-highlight suppresses git-config's stderr, so dump
# trace through descriptor 3
git show d1f33c753d | GIT_TRACE=3 diff-highlight 3>&2 >/dev/null
which drops from 6 lines down to 1.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Scott Baker [Mon, 23 Mar 2026 06:02:15 +0000 (02:02 -0400)]
diff-highlight: allow module callers to pass in color config
Users of the module may want to pass in their own color config for a few
obvious reasons:
- they are pulling the config from different variables than
diff-highlight itself uses
- they are loading the config in a more efficient way (say, by parsing
git-config --list) and don't want to incur the six (!) git-config
calls that DiffHighlight.pm runs to check all config
Let's allow users of the module to pass in the color config, and
lazy-load it when needed if they haven't.
Signed-off-by: Scott Baker <scott@perturb.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Mon, 23 Mar 2026 06:02:13 +0000 (02:02 -0400)]
diff-highlight: test color config
We added configurable colors long ago in bca45fbc1f (diff-highlight:
allow configurable colors, 2014-11-20), but never actually tested it.
Since we'll be touching the color code in a moment, this is a good time
to beef up the tests.
Note that we cover both the highlight/reset style used by the default
colors, as well as the normal/highlight style added by that commit
(which was previously totally untested).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Mon, 23 Mar 2026 06:02:10 +0000 (02:02 -0400)]
diff-highlight: use test_decode_color in tests
The diff-highlight tests use raw color bytes when comparing expected and
actual output. Let's use test_decode_color, which is our usual technique
in other tests. It makes reading test output diffs a bit easier, since
you're not relying on your terminal to interpret the result (or worse,
interpreting characters yourself via "cat -A").
This will also make it easier to add tests with new colors/attributes,
without having to pre-define the byte sequences ourselves.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Mon, 23 Mar 2026 06:02:07 +0000 (02:02 -0400)]
t: add matching negative attributes to test_decode_color
Most of the ANSI color attributes have an "off" variant. We don't use
these yet in our test suite, so we never bothered to decode them. Add
the ones that match the attributes we encode so we can make use of them.
There are even more attributes not covered on the positive side, so this
is meant to be useful but not all-inclusive.
Note that "nobold" and "nodim" are the same code, so I've decoded this
as "normal intensity".
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Mon, 23 Mar 2026 06:02:05 +0000 (02:02 -0400)]
diff-highlight: check diff-highlight exit status in tests
When testing diff-highlight, we pipe the output through a sanitizing
function. This loses the exit status of diff-highlight itself, which
could mean we are missing cases where it crashes or exits unexpectedly.
Use an extra tempfile to avoid the pipe.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Scott Baker [Mon, 23 Mar 2026 06:02:02 +0000 (02:02 -0400)]
diff-highlight: drop perl version dependency back to 5.8
The diff-highlight code does not rely on any perl features beyond what
perl 5.8 provides. We bumped it to v5.26 along with the rest of the
project's perl scripts in 702d8c1f3b (Require Perl 5.26.0, 2024-10-23).
There's some value in just having a uniform baseline for the project,
but I think diff-highlight is special here:
- it's in a contrib/ directory that is not frequently touched, so
there is little risk of Git developers getting annoyed that modern
perl features are not available
- it provides a module used by other projects. In particular,
diff-so-fancy relies on DiffHighlight.pm but does not otherwise
require a perl version more modern than 5.8.
Let's drop back to the more conservative requirement.
Signed-off-by: Scott Baker <scott@perturb.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Mon, 23 Mar 2026 06:01:58 +0000 (02:01 -0400)]
diff-highlight: mention build instructions
Once upon a time, this was just a script in a directory that could be
run directly. That changed in 0c977dbc81 (diff-highlight: split code
into module, 2017-06-15). Let's update the README to make it more clear
that you need to run make.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sat, 21 Mar 2026 16:25:58 +0000 (09:25 -0700)]
Merge branch 'master' of https://github.com/j6t/git-gui
* 'master' of https://github.com/j6t/git-gui:
git-gui: grey out comment lines in commit message
git-gui: wire up "git-gui--askyesno" with Meson
git-gui: massage "git-gui--askyesno" with "generate-script.sh"
git-gui: prefer shell at "/bin/sh" with Meson
git-gui: fix use of GIT_CEILING_DIRECTORIES
git-gui: shift tabstops to account for the first column of patch text
Junio C Hamano [Sat, 21 Mar 2026 16:25:10 +0000 (09:25 -0700)]
Merge branch 'master' of https://github.com/j6t/gitk
* 'master' of https://github.com/j6t/gitk:
gitk: l10n: make PO headers identify the Gitk project
gitk: ignore generated POT file
gitk: i18n: use "Gitk" as package name in POT file
gitk: commit translation files without file information
gitk: support link color in the Preferences dialog
gitk: use config settings for head/tag colors
Johannes Sixt [Fri, 20 Mar 2026 08:23:32 +0000 (09:23 +0100)]
Merge branch 'jx/i18n-fix' of github.com:jiangxin/gitk
* 'jx/i18n-fix' of github.com:jiangxin/gitk:
gitk: l10n: make PO headers identify the Gitk project
gitk: ignore generated POT file
gitk: i18n: use "Gitk" as package name in POT file
Jeff King [Tue, 17 Mar 2026 23:02:23 +0000 (19:02 -0400)]
contrib/diff-highlight: do not highlight identical pairs
We pair lines for highlighting based on their position in the hunk. So
we should never see two identical lines paired, like:
-one
-two
+one
+something else
which would pair -one/+one, because that implies that the diff could
easily be shrunk by turning line "one" into context.
But there is (at least) one exception: removing a newline at the end of
a file will produce a diff like:
-foo
+foo
\No newline at end of file
And we will pair those two lines. As a result, we end up marking the
whole line, including the newline, as the shared prefix. And there's an
empty suffix.
The most obvious bug here is that when we try to print the highlighted
lines, we remove the trailing newline from the suffix, but do not bother
with the prefix (under the assumption that there had to be a difference
_somewhere_ in the line, and thus the prefix would not eat all the way
up to the newline). And so you get an extra line like:
-foo
+foo
\No newline at end of file
This is obviously ugly, but also causes interactive.diffFilter to
(rightly) complain that the input and output do not match their lines
1-to-1.
This could easily be fixed by chomping the prefix, too, but I think the
problem is deeper. For one, I suspect some of the other logic gets
confused by forming an array with zero-indexed element "3" in a
3-element array. But more importantly, we try not to highlight whole
lines, as there's nothing interesting to show there. So let's catch this
early in is_pair_interesting() and bail to our usual passthrough
strategy.
Reported-by: Scott Baker <scott@perturb.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jiang Xin [Thu, 19 Mar 2026 09:11:17 +0000 (17:11 +0800)]
gitk: l10n: make PO headers identify the Gitk project
Commit f697d08 (gitk: i18n: use "Gitk" as package name in POT file,
2026-03-19) updated the generated POT template to use "Gitk" in its
Project-Id-Version header. Several existing PO files still carry older
header values such as "git" or "git-gui", so they do not consistently
identify themselves as Gitk translations.
Update the Project-Id-Version field in all Gitk PO files so that they
identify the Gitk project consistently.
The "Project-Id-Version" field in the PO header helps tools identify
which project a PO file belongs to. For example, Git's
"git-po-helper" uses it to choose project-specific checks and POT
handling rules. Without this change, some Gitk PO files are
misidentified because their headers still refer to other projects.
Junio C Hamano [Thu, 19 Mar 2026 22:39:02 +0000 (15:39 -0700)]
cocci: strbuf.buf is never NULL
We recently noticed one old code from 19 years ago protecting
against an ancient strbuf convention that the .buf member can be
NULL for an empty strbuf. As that is no longer the case in the
modern codebase, let's catch such a construct.
Jiang Xin [Thu, 19 Mar 2026 09:08:47 +0000 (17:08 +0800)]
gitk: ignore generated POT file
"po/gitk.pot" is generated from the source for translation maintenance.
Ignore it in the working tree so regenerating the template does not
introduce unnecessary noise in `git status`.
Jiang Xin [Thu, 19 Mar 2026 09:06:25 +0000 (17:06 +0800)]
gitk: i18n: use "Gitk" as package name in POT file
Use "Gitk" instead of the placeholder "PACKAGE" in the header of the
generated po/gitk.pot file. In particular, the "Project-Id-Version"
field in the header entry should be set to:
"Project-Id-Version: Gitk\n"
New PO files generated from this POT file will inherit that package
name.
René Scharfe [Thu, 19 Mar 2026 16:24:40 +0000 (17:24 +0100)]
commit-reach: simplify cleanup of remaining bitmaps in ahead_behind ()
Don't bother extracting the last few remaining prio_queue items in
order when we only want to free their associated bitmaps; just iterate
over the item array.
Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Thu, 19 Mar 2026 16:54:56 +0000 (09:54 -0700)]
Merge branch 'ps/unit-test-c-escape-names.txt'
The unit test helper function was taught to use backslash +
mnemonic notation for certain control characters like "\t", instead
of octal notation like "\011".
Junio C Hamano [Thu, 19 Mar 2026 07:15:59 +0000 (00:15 -0700)]
rerere: update to modern representation of empty strbufs
Back when b4833a2c (rerere: Fix use of an empty strbuf.buf,
2007-09-26) was written, a freshly initialized empty strbuf
had NULL in its .buf member, with .len set to 0. The code this
patch touches in rerere.c was written to _fix_ the original code
that assumed that the .buf member is always pointing at a NUL-terminated
string, even for an empty string, which did not hold back then.
That changed in b315c5c0 (strbuf change: be sure ->buf is never ever
NULL., 2007-09-27), and it has again become safe to assume that .buf
is never NULL, and .buf[0] has '\0' for an empty string (i.e., a
strbuf with its .len member set to 0).
A funny thing is, this piece of code has been moved around from
builtin-rerere.c to rerere.c and also adjusted for updates to the
hash function API over the years, but nobody bothered to question
if this special casing for an empty strbuf was still necessary:
b4833a2c62 (rerere: Fix use of an empty strbuf.buf, 2007-09-26) 5b2fd95606 (rerere: Separate libgit and builtin functions, 2008-07-09) 9126f0091f (fix openssl headers conflicting with custom SHA1 implementations, 2008-10-01) c0f16f8e14 (rerere: factor out handle_conflict function, 2018-08-05) 0d7c419a94 (rerere: convert to use the_hash_algo, 2018-10-15) 0578f1e66a (global: adapt callers to use generic hash context helpers, 2025-01-31)
Finally get rid of the special casing that was unnecessary for the
last 19 years.
Every compilation unit in Git is expected to include "git-compat-util.h"
first, either directly or indirectly via "builtin.h". This header papers
over differences between platforms so that we can expect the typical
POSIX functions to exist. Furthermore, it provides functionality that we
end up using everywhere.
This header is thus quite heavy as a consequence. Preprocessing it as a
standalone unit via `clang -E git-compat-util.h` yields over 23,000
lines of code overall. Naturally, it takes quite some time to compile
all of this.
Luckily, this is exactly the kind of use case that precompiled headers
aim to solve: instead of recompiling it every single time, we compile it
once and then link the result into the executable. If include guards are
set up properly it means that the file won't need to be reprocessed.
Set up such a precompiled header for "git-compat-util.h" and wire it up
via Meson. This causes Meson to implicitly include the precompiled
header in all compilation units. With GCC and Clang for example this is
done via the "-include" statement [1].
This leads to a significant speedup when performing full builds:
Benchmark 1: ninja (rev = HEAD~)
Time (mean ± σ): 14.467 s ± 0.126 s [User: 248.133 s, System: 31.298 s]
Range (min … max): 14.195 s … 14.633 s 10 runs
Benchmark 2: ninja (rev = HEAD)
Time (mean ± σ): 10.307 s ± 0.111 s [User: 173.290 s, System: 23.998 s]
Range (min … max): 10.030 s … 10.433 s 10 runs
Summary
ninja (rev = HEAD) ran
1.40 ± 0.02 times faster than ninja (rev = HEAD~)
In the next commit we're about to introduce a precompiled header for
"git-compat-util.h". The consequence of this change is that we'll
implicitly include that header for every compilation unit that uses the
precompiled headers.
This is okay for our "normal" library sources and our builtins. But some
of our compatibility sources do not include the header on purpose, and
doing so would cause compilation errors.
Prepare for this change by splitting out compatibility sources into
their static library. Like this, we can selectively enable precompiled
headers for the library sources.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
projects / rit / log