My ban from the Git project: the defense I was denied

On 2023-05-13 I was notified of my permanent ban of the Git project by the The Git Project Leadership Committee.

I already explained in another post that the Git PLC did not do any due diligence regarding my ban, did not do any effort to notify me of any issue, and used lies to attempt to justify my permanent ban (for example, they claimed I was temporarily banned before, when that’s not true).

The Git PLC did not give me any warning prior to my permanent ban nor did allow me to defend myself. They simply notified me, blocked me from the mailing list, and never replied again.

Everyone deserves their day in court. Everyone.

After 15 years of contributions, 1604 patches, and 6564 messages in the mailing list, the Git PLC didn’t I think I deserved a single reply. Not even to say “no, we are not going to give you anything, or reply anymore”.

Without my defense, their judgement is null and void. The violations they listed are alleged, not necessarily real.

Since I wasn’t allowed to defend myself, here is my defense, and you’ll be the judge.

Code of Conduct

When the code of conduct was proposed, a selling point was that “nothing would change“: the document was supposed to outline the practices that were already in place:

Keep in mind that a lot of this isn’t changing the status quo. When we had a problem on the mailing list in the past, it was discussed on the list and in private. And ultimately decisions came down to the maintainer: am I going to start ignoring this person’s patches, or will I continue to encourage them to interact with the project even though they’re causing problems.

So I think a lot of this is really just writing down the current practice.

Jeff King

The practice at the time is that if a person was “difficult”, that person was ignored. But because there’s always differences of opinion, not everyone found the same people “difficult”, and not everyone ignored the same people.

For example, some people found working with me difficult, but other people did not.

But this selling point turned out to be untrue. In typical wedge strategy fashion, once the Code of Conduct was in place, the wording of the document was used to change the status quo.

Permanent Ban

The CoC document which is a verbatim copy of Contributor Covenant says about permanent bans:

**Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.

**Consequence**: A permanent ban from any sort of public interaction within the community.

CODE_OF_CONDUCT.md

This is clearly directed towards obvious troublemakers. Did I harass anybody? Did I act aggressively towards disparaged classes or individuals? Of course not!

What the Git PLC claimed is that:

You have demonstrated a pattern of violating our standards with your sustained inappropriate behavior.

Git PLC

Of course, what “our standards” are is completely subjective and not defined anywhere, as is “inappropriate behavior”.

This is so vague it might as well read “we think you did bad”.

Examples

To justify their permanent ban, the Git PLC used examples from four emails in two threads. 4 out of 6564 emails.

Examples in red, emails after CoC in yellow

Is GIT_DEFAULT_HASH flawed?

In this thread I raised genuine concern that the entire design behind the plan to move from SHA-1 to SHA-256 was flawed. Maybe there is no issue, I myself argued that I’m not an expert in the area, but it seems worrying to me.

The Git community accepts and encourages participants to engage in substantive technical review, and to raise concerns where they exist.

However, your conduct in this thread appears in bad-faith through its lack of respect to the thorough discussion and community review process that took place to come to the hash transition plan we have today.

Git PLC

The question is not if I appear to act in bad faith, the question is if I did.

Further, your conduct in [2, 3, 4] is rude towards the recipients, and is thus unacceptable on the Git mailing list. Specifically, we consider the following excerpts to be in conflict with our community guidelines:

• “Do you understand how checksums work?”
• “I don’t know if you are aware, but Linus Torvalds is the author of git.”
• “Then you would have no trouble steel manning my argument, which you haven’t done.”
• “Yeah? Provide me with one mail proposing my approach.”

Git PLC

Re: Is GIT_DEFAULT_HASH flawed?

Without context asking the question “Do you understand how checksums work?” might seem rude, but if you look at the context, it’s just a rhetorical device:

> >It’s completely different.
>
> How so? Type and size are just about 2 and a dozen bits of data, respectfully.

Do you understand how checksums work?

Compare these two objects:

1. 0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33
2. 6ba62a7c5e3e9a260c5a30adf2756882c02f12a6

Are they a) “not much different”, or b) “completely different”?

Answer: doesn’t matter, they are different. Period.

Felipe Contreras

I’m not trying to be rude towards Adam Majer. I presume he does know how checksums work, and the way checksums work is that any tiny difference should generate an entirely different checksum. Therefore when he asks how is it that a few bits of data could be considered “completely different”, the answer should be self-explanatory if you just consider how checksums work, which is what invited him to do through a rhetorical question.

Moreover, if you consider this question so rude that it’s a violation of the standards of the project, compare it the kinds of things Junio C Hamano says:

So I do not think this is not even a bikeshedding. Just one side being right, and the other side continuing to repeat nonsense without listening.

Junio C Hamano

One is perfectly fine, the other completely unacceptable. On what basis?

> I’m not sure why you are name dropping Linus everywhere

I don’t know if you are aware, but Linus Torvalds is the author of git.

He also happens to be the author of the most successful software project in history: Linux.

So generally his design choices are considered to be good.

Felipe Contreras

I truly don’t know if he was aware, because if he was, then I don’t think he would be asking how is Linus Torvalds’ view of security relevant to the design of Git objects. Not everyone knows everything.

I’m a skeptic, I try pretty hard to avoid making assumptions, and I don’t assume everyone knows everything that I do. The curse of knowledge is a well known bias that all experts suffer from, and I’ve argued in the past that Git developers suffer from it, for example: they assume everyone knows what a rebase is, what an upstream tracking branch is, what the index is, etc.

I don’t think the PLC should punish me for being a skeptic, thinking differently, and considering a certain possibility. Isn’t diversity something they are supposed to be fostering?

How about Junio here?

As you are supposed to be one of the top-level Git Teachers, I wish you knew better. Here is a free Git lesson.

Junio C Hamano

Being condescending towards towards one of the most important personalities in the Git teaching industry: totally kosher. Questioning if one person knows a particular factoid: unforgivable sin.

> Your explanation is quite clear to me (and probably everyone else here). But I’ll just leave it at that.

Is it? Then you would have no trouble steel manning my argument, which you haven’t done.

Felipe Contreras

Once again: I’m being skeptical. What is the problem with that?

I’m not denying that my explanation was clear to him, I’m questioning if that’s actually the case.

If it was the case, then he wouldn’t have any trouble explaining it, which he didn’t do. If he did, then I would confirm: “yes, that’s my view”. If not, then I would clarify what is my view.

That’s the whole point of a steel man argument: to confirm what your counterpart is arguing.

How is questioning a claim a violation of the standards?

Should I follow Junio’s example instead:

Your elaborate scheme to make “pull” into “fetch” and to force everybody to set a configuration variable to make it “pull” again sounds like a mindless mental masturbation to me.

Junio C Hamano

Much more polite.

All three of the examples provided so far are on the same email. In their argument that I violated the standards “repeatedly”, they used the same email three times.

The standards of the project are not whatever the PLC wish them to be, they are what they are. I could fill pages and pages with examples of comments that are way more rude than “Do you understand how checksums work?”. All git developers express themselves in ways that could be considered “rude”, including the maintainer. This is not an objective basis for a permanent ban, this is an excuse.

Yeah? Provide me with one mail proposing my approach.

Context:

> However, I refer you to the list archives to determine why your approach is not the one we chose and is not, in my view, the best path forward.

Yeah? Provide me with one mail proposing my approach.

Felipe Contreras

Once again: I’m not allowed to question the claims of other people? I truly doubt somebody else has made exactly the same proposal, but it’s possible, if so, I would like to see it.

How is requesting a source a violation?

It’s much better to question the good faith of the contributor as Junio teaches us:

You either did not read what I wrote earlier in the thread or you are trying to paint a picture that is different from reality with whatever motive you have.

Junio C Hamano

[PATCH 0/6] test: make the test suite work with zsh

In this thread I tried to make the test suite work with zsh, as the title clearly says. What people had a problem with was the first patch, which essentially did something like ARGZERO="$0" and changes instances of $0 to $ARGZERO, and then if zsh is used ARGZERO is set to something else.

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

This is simply not a real consideration.

Context:

> > One aspect that is missing in the above is the extra burden on our developers.
>
> Well said.
>
> Having to remember that we need to write “$ARGZERO” instead of “$0”

When have you ever used “$0” in the test suite?

A quick grep shows zero results (git log --author=me@ttaylorr.com -S'$0'), so I think you are talking about a hypothetical, not something that would actually happen in reality.

Sometimes preemptive optimization pays off in the future, but other times it doesn’t, and it’s just wasted mental effort.

This is one of those times when worrying about a future that will never happen in reality does not pay off.

> Is that a big deal? Probably not. But it’s a slippery slope, and a weird gotcha to remember when dealing with our otherwise POSIX-y test suite.

You won’t have to remember that because you’ll never use $0 in the test suite. Nobody does use it, and nobody ever will.

If for some weird reason somebody needs to use $0, we can worry about it then.

---

But this is a red herring. The reality is that developers do not have to worry about every little aspect of the test suite. When somebody uses seq, somebody else reminds them to use test_seq instead, and if for some reason a seq slips by and it breaks the test in some obscure platform, the test is updated to fix that. It’s not a big deal.

Why are many tests using chmod instead of test_chmod? Did the introduction of test_chmod imply an extra burden to “our developers” to remember using that instead of chmod? No, in reality what everyone cares about is that the test runs on the platforms of the real world.

If we could run the test suite on 100 hypothetical platforms that don’t exist in the real world, it would break all over the place.

In reality all the portability considerations of the test suite are geared towards certain platforms that exist in the real world. Nobody cares that the test suite doesn’t run on some hypothetical platforms.

So no, nobody needs to remember to use test_chmod, or test_seq, and nobody will ever have to remember to use $ARGZERO instead of $0, and if some hypothetical person does use that in some hypothetical test and that breaks the tests for zsh in native mode, nobody will care, except the person running those tests (likely me), which would promptly fix that single hypothetical instance of $0.

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

This is simply not a real consideration.

Cheers.

Felipe Contreras

I went through great pains to explain why in my opinion Git developers would not have to remember to use $ARGZERO instead of $0, and the fact is that $0 is not used in any test case, and in my opinion it never will.

Taylor may disagree with my opinion, but he cannot reasonably say that I “dismissed” and “deflected” his criticism.

I addressed his claim in detail. The conclusion of my assessment is that this is not something that will actually happen in reality.

Why am I being punished for having and expressing a well-founded opinion? Because it destroys Junio C Hamano and Taylor Blau’s claim?

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

Context:

> 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.

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

Felipe Contreras

Junio C Hamano has the impression that zsh is pretty far away from POSIX and would be unreasonable for Git developers to support zsh in the test suite for that very reason.

However, he has that impression by never actually using zsh, nor tested any patch I’ve sent meant for zsh.

So whatever impression he has of zsh, it’s not based on his actual experience, but probably something he heard someone say, or something along those lines. That is my impression after 12 years of sending him zsh fixes.

Moreover, I know his impression is not accurate because in the process of discussing this patch I found an easier way to support zsh:

emulate sh -o POSIX_ARGZERO

Just one line of code makes Git’s test suite work for zsh. So zsh can be told to act closer to POSIX and everything works without “forcing our developers to adjust to” anything.

The rationale Junio used to not support zsh is just not valid.

But even if it was, disagreeing with him should not be a violation. And I didn’t even say his impression was false, I said it wasn’t necessarily true.

Suggesting that Junio isn’t infallible is a violation?

---

The absence of a patch message [7] led to confusion and questions among people who were expecting an explanation. Despite this, you chose to respond dismissively and impolitely rather than participating in the review, which further exacerbated the situation.

Git PLC

So now it’s a CoC violation to send a patch with an imperfect message? People send subpar v1 patches all the time. That’s what the review process is for: to find issues. And those issues include things that are not clear to other people. If something is not clear, that’s fixed in v2. Moreover, even though no one objected to the lack of a commit message, I still sent a simpler patch with a detailed commit message a few days later: [PATCH 1/2] test: fix build for zsh.

Responding is participating.

The fact that in my response I dismantled Taylor’s claim and therefore he didn’t like it doesn’t make it a violation.

Excuses

As the examples above clearly show, this is not about me engaging in “inappropriate behavior”. This is about me disagreeing with members of the Git PLC who clearly have an issue with me. This is about me not being subservient and paying deference to them.

Two of the four examples they used were responses to members of the committee, and two of them the opinion of Junio C Hamano is involved (who hates me and is a member of the committee). So they were the ones who made the report, and they were the ones who decided the report was valid.

The Code of Conduct which was originally intended to protect members from harassment, bigotry, and other egregious behavior while keeping the status quo, has now been hijacked to fulfill the whims of capricious members who do not like when their opinions are challenged and are changing the status quo to prevent that.

Using the Code of Conduct as an excuse to punish members for merely expressing an opinion some do not find palatable without any warning, any due process, any ability to defend themselves, and any recourse sets a very dangerous precedent.

I also don’t think it bodes well for the future of the project that the PLC does not value 15 years of contributions done entirely on a voluntary basis. It’s not good that the PLC can so easily dismiss a contributor with so many hours devoted to the project without any consideration and any due diligence.

The PLC needs to remember that the victims of their decisions are human, and they are not infallible monarchs, but humans capable of making mistakes and misinterpreting their fellow humans.