Proof that the Git project doesn’t allow criticism

It may sound sensationalist to say that I have irrefutable proof that the Git project doesn’t allow criticism, but it’s true. I have tons of evidence of this, but in this article I will focus only on one disagreement that is the easiest to understand.

In this case I provided a patch, the maintainer mentioned a problem, I explained how it wasn’t a problem, and you will be the judge if his reaction was justified.

Why would this matter? Well, the whole point of having diverse people in an organization is that different people have different points of view and they can come up with solutions that other people don’t. In a homogeneous culture the danger of an echo chamber — where everyone thinks the same — is high.

This danger is not dissipated if the diverse group of people are not allowed to disagree. If the benevolent dictator can’t be criticized, that pretty much ensures an echo chamber.

Junio C Hamano is the appointed dictator of the Git project, he is supposed to be benevolent and allow criticism of his ideas, but he doesn’t, and I’ll prove that.

Without a healthy dose of criticism ideas stagnate, which is precisely what has happened to the Git project. Only people who don’t criticize Junio are allowed, and that ensures a certain kind of people, and certain kinds of ideas.

The patch

This is the offending patch: test: fix build for zsh. The context of this patch is that git’s test suite which is written in shell script didn’t work on zsh and I came up with a way to make it work. All I did was use $ZSH_ARGZERO instead of $0 if zsh is used. That’s all.

Update: some people are wrongly concluding that the motivation for this patch was to be able to run the tests with zsh instead of sh: that’s not true. The motivation was explained in a subsequent patch series test: add support for zsh and zsh completion: to add tests for zsh completion. Being able to run the entire test suite with zsh was just a bonus.

Why would Junio object to such seemingly innocuous change? Well, the way I implemented the change was by introducing a new variable $ARGZERO, which contained either $0 or $ZSH_ARGZERO, and then replaced all the current instances of $0 with $ARGZERO (6 instances). Junio argued that if we did that, then everyone would have to remember to use $ARGZERO instead of $0.

Here’s the problem with Junio’s argument: it wasn’t true.

What Junio said is not just wrong, it’s wrong on multiple levels. First, he is worrying prematurely about something that will not happen and git historically has dealt with as the issues come. Second, even if the “issue” appeared, it would be in a part of the tests where it does not matter. Third, even if the issue appeared in a part where it does matter, it would be a problem only on zsh, and it would be fixed when somebody who uses zsh catches it, the rest of the developers do not need to worry about it. Fourth, even if developers did end up with a mental burden, it would not be all of them, just like not all developers know all the current considerations.

There’s a fifth reason that makes all of these irrelevant, but let’s go step by step.

Organization

To understand the first reason why he is wrong, we need to take a quick look at the organization of the tests. In git’s test suite tests are numbered, the first one is t0000-basic.sh, the second one t0001-init.sh, and so on. Every single one of these tests sources the library test-lib.sh.

Not a single one of the tests makes use of the $0 variable. Not one.

Therefore nobody writing tests needs to learn my proposed change to $ARGZERO because currently $0 is only used in the library test-lib.sh.

Case closed. Junio’s claim that we need to “force our developers to pay attention” is false. Nobody writing tests needs to pay attention. The variable is contained in the library — which is seldom modified — and is not used in the tests.

But let’s give Junio the benefit of the doubt and assume that in the future tests could make use of $0, and the developers would need to pay attention and use $ARGZERO instead.

At this point it might be useful to explain that if you run a shell script like ./t0000-basic.sh, then $0 would be ./t0000-basic.sh. This is something that is not useful inside the tests, and that’s why not one of the 997 tests use it. But let’s pretend that for some strange reason they might.

Nuance

Let’s suppose somebody writes a hypothetical test that does use $0 and my patch is applied. According to Junio, we have to “force our developers to pay attention” and use $ARGZERO instead.

What happens if we don’t? If they use $ARGZERO they will correctly get “./t0000-basic.sh“, but if they use $0 instead they get “./t0000-basic.sh“. Wait… are they the same?

Yeap, they are exactly the same.

Then why did I introduce $ARGZERO in the first place? That’s where expertise in different shell script implementations comes into play, an expertise that Junio seems to lack.

Let’s suppose we have two files, one with a library, and one with a script that sources that library:

## lib.sh
echo "lib: $0"

## script.sh
source ./lib.sh
echo "script: $0"

If we run script.sh with bash (and most POSIX-aligned shells), both instances are going to return ./script.sh, but if we run it with zsh, then the one inside lib.sh is going to return ./lib.sh. So the meaning of $0 is different in zsh: it means the name of the current script. This changes when a script is sourced, but otherwise it’s the same (the name of the script is the name used to invoke the shell).

Because t0000-basic.sh is a script that is not sourced, $0 is the same in bash and zsh. There is no need to use $ARGZERO in this case.

Case closed. Twice. Junio’s claim that we need to “force our developers to pay attention” is not true. They can use $0 in test scripts just fine. It’s only in test-lib.sh which is sourced where it makes a difference.

At this point it’s not possible to give Junio the benefit of the doubt: there’s no possible universe in which git developers need to pay attention to this, but for the sake of argument let’s suppose that someone does modify test-lib.sh and they introduce a $0 where it does make a difference.

The humanity!

What happens if somebody does introduce a $0 after my $ARGZERO patch? Nothing.

In all the shells currently being used there would be no difference, only in zsh would it make a difference, and only if somebody runs it directly. The difference might not cause any trouble, depending on which tests they run, and which options they use.

But that situation could not be worse than the current situation, where tons of tests already fail if you run them with zsh.

So even in the worst possible scenario we could end up in this extremely hypothetical situation, it’s still better than the current situation.

If that hypothetical situation were to happen, what shall we do? Is humanity lost? No, if somebody notices a new problem with zsh, they send a patch changing the new $0 to $ARGZERO. That’s it.

Case closed. Thrice. Junio’s claim that we need to “force our developers to pay attention” is still not true. Nobody needs to pay attention if this situation happens (which is never going to), then it would just get fixed by somebody who cares about zsh.

I could go into an ever more hypothetical situation, but you get the point: it’s still not going to be every developer that needs to pay attention.

Criticism

I told Junio that we do not need to “force our developers to pay attention” and I explained the reasons why.

He ignored my argument and simply reiterated his position:

One aspect that is missing in the above is the extra burden on our developers.

Junio C Hamano

Then one of his lieutenants — Taylor Blau — pandered to him:

Well said.

Having to remember that we need to write “$ARGZERO” instead of “$0” is yet another burden to place on developers who want to make changes to the test suite.

Taylor Blau

I then went into great detail explaining to Taylor why that was not the case — he was worrying about a hypothetical case that would never happen, and if it did it would be easy to fix — ending with:

Nobody will die if a instance of $0 slipped by (which will never happen).

This is simply not a real consideration.

Felipe Contreras

What was their response to my audacity to criticize their claim?

Permanent ban

That’s right, soon after this disagreement, they permanently banned me from the project and 2 out of the 4 examples of “sustained inappropriate behavior” they used came from this thread.

In your series to modify the test suite to work with zsh, you repeatedly dismiss and deflect [5, 6] from technical critique from other list participants:

• “This is simply not a real consideration.”
• “Just because it’s your impression doesn’t mean it’s true.”

Git PLC

According to the Git’s Project Leadership Committee (50% of which is comprised by Junio and Taylor), me stating my opinion that Junio’s claim is not a real consideration is reason for a permanent ban.

There was no warning, no due process, no ability to defend myself, no recourse. After 15 years of contributions, 1604 patches, and 6564 messages in the mailing list, they simply sent me a notification, blocked me from the mailing list, and never replied again. All the work I did for git was entirely on a voluntary basis, the opposite of Junio’s cadre — who are all paid to work on git.

According to them, I “dismissed and deflected” their technical critique, when in fact in that very email I wrote 404 words explaining why I believed this was not a real consideration. They are the ones who did not defend their position, dismissed my critique, and stopped responding.

But wait.. there’s more.

Never surrender

I know the drill, this wasn’t the first time Junio rejected a perfectly valid solution with what I believed to be bullshit reasons. The truth is that he just doesn’t care about zsh, as evidenced by the dozens of fixes he has ignored for years.

The claim that we needed to “force our developers to pay attention” was obviously false, as I demonstrated above. It was merely an excuse, but if our “benevolent” dictator was not willing to listen, was that the end of the road?

No, I kept looking for an alternative solution that did not require debate, and I found one. It turns out that that zsh has an option to make $0 work as $ZSH_ARGZERO, all that was needed was one line to turn it on: emulate sh -o POSIX_ARGZERO.

I did tell them about my new solution in the thread, and I did send the patch: test: fix build for zsh.

Case closed. Five times. What was Junio’s excuse for not applying the patch now? No reply.

Wrong again

The other example of “sustained inappropriate behavior” according to them also came from this thread, where I dared to challenge one impression of Junio:

It is my impression, however, that zsh in its native mode is even further out and away, pushing it on the other side of the line of being reasonable to force our develoerps to adjust to.

Junio C Hamano

Is it such a sin to challenge Junio’s impression? Let’s remember that Junio has never used zsh, nor tested any patch for it. So it’s not outlandish to wonder how he got that impression.

But in fact, we do know his impression was wrong, because zsh is actually not as further away from POSIX as he thought, all we needed to do is enable POSIX_ARGZERO, and boom, it’s basically compatible with git’s test suite with zero effort required from the developers.

Moreover, I didn’t even claim that he was wrong, I said his impression was not necessarily true, which is different.

Just because it’s your impression doesn’t mean it’s true.

Felipe Contreras

Why is it a sin to suggest that Junio’s impression might not be true? Especially when in fact, it wasn’t true.

Thou shalt not contradict Junio

I have shown that I was right, Junio was wrong, and I got permanently banned from the project for merely suggesting that might be the case.

I have proved beyond reasonable doubt that they did ban me because I dared to contradict Junio. Now, you might be willing to still give them the benefit of the doubt and consider that perhaps the other 2 examples of “sustained inappropriate behavior” were more egregious. Feel free to read their entire rationale: My ban from the Git project: the defense I was denied. You’ll see that their case had no merit.

The truth of the matter is that the real reason why I got permanently banned is that Junio hates me, and he hates me because I often contradict him, but worse than that: I often turn out to be right. He does not like to be proven wrong. I have ample evidence for this, but it will take me time to compile and present it.

So now you might have an idea why git’s user interface has not improved substantially in more than a decade: git’s UI works perfectly fine for Junio and his echo chamber, anyone joining the project with hopes of improving the UI would have to challenge Junio, and that’s simply not permitted. If you don’t believe me, just try it. Additionally, you can read this summary of 13 years of discussions where literally everyone agrees with renaming one term… everyone except one person (you know who): The git staging area, the term literally everyone agrees with. The evidence speaks for itself.