Why Git Has a Variable Named false_but_the_compiler_does_not_know_it_
SubscribeSign in
Why Git Has a Variable Named false_but_the_compiler_does_not_know_it<br>A small C trick that keeps Clang from flagging valid code as unreachable
Abhinav Upadhyay<br>Jun 03, 2026
Share
Today, in weird C code tricks, I want to show you a small example from Git’s source code.<br>Recently, I was poking around the Git source when a directory name caught my eye, it was named “compiler-tricks”. I thought, “This is a promising name, let’s see what’s inside of it”.<br>Inside this directory, there was a file called not-constant.c, and the whole file contained just this:<br>#include<br>int false_but_the_compiler_does_not_know_it_ = 0;
The variable name made me curious. Why would Git need a global variable whose name says that the value is false, but the compiler does not know it?<br>To understand this, let’s first look at where this variable is used.<br>It is used inside a macro called NOT_CONSTANT in git-compat-util.h:<br>/*<br>* Prevent an overly clever compiler from optimizing an expression<br>* out, triggering a false positive when building with the<br>* -Wunreachable-code option. false_but_the_compiler_does_not_know_it_<br>* is defined in a compilation unit separate from where the macro is<br>* used, initialized to 0, and never modified.<br>*/
#define NOT_CONSTANT(expr) ((expr) || false_but_the_compiler_does_not_know_it_)
extern int false_but_the_compiler_does_not_know_it_;
The macro takes an expression and performs a logical OR with this global variable:<br>(expr) || false_but_the_compiler_does_not_know_it_
Now, the global variable is initialized to 0, and Git never modifies it (I checked the entire Git codebase). So, logically, this expression is equivalent to:<br>(expr) || 0
which is simply:<br>exprSo, why write the code this way?<br>The variable false_but_the_compiler_does_not_know_it_ is not declared as const. It also has external linkage and is defined in a different translation unit from the code that uses it. As a result, while compiling a file that uses NOT_CONSTANT, the compiler cannot prove that the value of this variable will always remain 0.<br>In practice, it is always 0. But from the compiler’s point of view, someone else could modify it.<br>This is the whole trick. Git creates a value that is false at runtime, but not obviously false to the compiler. At this point, you might be wondering: what is the point of this trickery? To answer that, we need to look at where this macro is actually used.<br>Paid subscribers help me justify spending time on these strange little code rabbit holes. If you enjoy this kind of systems writing, consider upgrading.
Subscribe
Tripo AI Raises Nearly $200M to Advance AI 3D and World Models (Sponsored)
Tripo AI builds AI 3D foundation models for high-demand 3D workflows across interior design, e-commerce, gaming, film, VR/AR, digital twins, robotics, and interactive entertainment.<br>Used by more than 20 million users worldwide, Tripo AI helps creators, developers, and studios turn ideas into high-quality 3D assets faster, from product visualization and home design to game-ready assets and simulation workflows.<br>Following nearly $200 million in Series A+ and A++ financing, Tripo AI is accelerating its research roadmap, product development, and global creator ecosystem. Its new research initiative, Project Eden, explores how AI 3D can move beyond single-asset generation toward persistent, editable, reusable, multi-agent interactive worlds.<br>With Tripo AI, you can explore:<br>AI-generated 3D assets and production-ready meshes
Native 8K AI textures
Intelligent part segmentation for editable 3D workflows
Project Eden, Tripo AI’s world model research initiative
Start creating with Tripo AI →
Where Git Uses This Trick
So, the question is, where does Git use this macro? One of the interesting uses appears in refs/files-backend.c. Git has code that tries to create a symbolic ref using a symlink. If that succeeds, it continues to the next update. If it fails, it falls back to creating a regular symbolic ref.<br>The code looks like this:<br>/*<br>* By using the `NOT_CONSTANT()` trick, we can avoid<br>* errors by `clang`'s `-Wunreachable` logic that would<br>* report that the `continue` statement is not reachable<br>* when `NO_SYMLINK_HEAD` is `#define`d.<br>*/
if (NOT_CONSTANT(!create_ref_symlink(lock, update->new_target)))<br>continue;
To understand why this is needed, we need to look at how create_ref_symlink is defined.<br>Depending on the build configuration, it can either be a real function:<br>static int create_ref_symlink(struct ref_lock *lock, const char *target)<br>/* ... */
Or, it can be compiled away into a constant expression:<br>#if defined(NO_SYMLINK_HEAD) || defined(WITH_BREAKING_CHANGES)<br>#define create_ref_symlink(a, b) (-1)<br>#endif
So, when NO_SYMLINK_HEAD is defined, this expression:<br>!create_ref_symlink(lock, update->new_target)
effectively becomes:<br>!(-1)
In C, -1 is treated as true. Therefore, !(-1) is false. So, the compiler sees something like this:<br>if...