Hacker News Reader

Comment by michael_storm | Hacker News Reader

> Today, I specifically want to call attention to two commits by the lead maintainer of Git, Junio Hamano, that left the deepest scars.

Why call the maintainer out by name (and continually do so throughout the essay)? What purpose does that serve? To embarrass him for volunteering his time on an open source project that you've built your business on, just because you didn't like these two features he added? There was no personal behavior of his at play; he simply made some technical choices you disagree with.

Keep it technical, dude. This is ad-hominem and smug.

View on HN

>This is ad-hominem and smug.

As counterpoint, I didn't interpret it that way. The tone wasn't shaming a programmer for accidentally screwing up (e.g. It was Michael who deleted everything with UNIX command "rm -rf /* ").

Instead, today's blog was extending the conversation of the message he sent 3 months ago[1] and he had already put Junio Hamano's name in that post.

If you're trying to trace the intellectual history and rationale for why things were done a certain way, attaching a name to it is very common and it does not mean malicious intent.

I didn't see any ad-hominem attacks in the post but I can only guess that the repetition of "Hamano" in the text rubs people the wrong way.

[1] https://public-inbox.org/git/EA993AC0-022C-423D-ABD7-4747FA0...

(Author here) I've updated the post to reduce the repetition of "Hamano" in the text.

(Author here.) Let me begin by saying that this post is intended to be historical. If you've ever wondered why "git checkout" both switches branches and restores working-tree files, or if you've ever wondered why "git reset" both rewrites history and unstages hunks, this post has the answer.

History is about people making decisions. It wouldn't make sense to write about the history of nations without naming any names, and I think it wouldn't make sense here, either.

Second, while I am critical of these historical decisions, I don't purport to be better than Hamano. There's a whole section of this post saying that "you or I might have done the same thing" for the same reasons.

I especially don't accept your charge that this is "ad hominem." I don't argue that you should agree with me because who Hamano is. I don't (and wouldn't) call Hamano any names, call doubt on his character, or even question his intelligence or competence.

Everyone should evaluate these historical decisions on their own merits. But anyone who wants to understand why git works the way it does must understand that these are Hamano's decisions, and decide for themselves whether these decisions were good or bad.

EDIT: A number of comments here have said that the complaint has to do with the number of times I mention Hamano's name, so I've updated the post to remedy this.

I think parent took their criticism a bit far with "ad-hominem and smug", but the calling out of a specific individual makes me uncomfortable also.

The issue, I think, is that the specific name doesn't really add anything to the discussion: you don't actually contact Hamano and get his perspective, and you don't use the name to link any additional relevant information. You could omit the name entirely without detracting from what you're trying to say.

Including the name makes the (public!) criticism needlessly personal. Not really cool.

Thanks for updating your post.

> History is about people making decisions. It wouldn't make sense to write about the history of nations without naming any names, and I think it wouldn't make sense here, either.

Historians usually do quite a bit more research, including talking to participants. Much more context would be required before zeroing in on one person and saying it's his fault. Was there discussion beforehand? Why has no one changed it thus far? All you did was post to a noisy mailing list from which you expected no reply, then assumed that it was solely the committer's decision.

> I don't (and wouldn't) call Hamano any names, call doubt on his character, or even question his intelligence or competence.

But that's done implicitly when you tie his reputation up so thoroughly with choices that you wrote an entire essay disparaging. The damage is magnified when he's not given a real opportunity to explain himself. Although you stated in another comment you've now emailed him directly, which is a good call.

Hamano replied pointing me to this thread. https://public-inbox.org/git/Pine.LNX.4.64.0510171814430.336... Linus proposed adding the feature to git-checkout, subsuming git-checkout-index. Junio expressed concern about file/branch ambiguity; Linus wrote back, "Yes, I know it's ambigious at times, but it really is very convenient. Usually we allow a "--" to say where a filename starts when it is ambiguous."

I think a separate command would have been convenient, too. ¯\_(ツ)_/¯

Good to know. I hope that your essay will be updated to reflect that.

I dunno, I think it's fine -- the article never attacks Hamano or calls him a bad person. Criticizing a person's decisions on technical grounds isn't an ad hominem argument, whether you mention them by name or not.

The author personalizes (literally) the problem: The problem is that Junio Hamano made these bad decisions, Junio Hamano wrote this code, Junio Hamano made git worse. And what about the code reviewers, the other people he discussed with, others who could have improved the system? No, it's all Junio Hamano's fault.

Elsewhere in codeland we usually say "this code is doing the wrong thing" not "Bob did the wrong thing."

In the section titled "You or I might have done the same thing" the author says "if I were Hamano, I probably would have made the same mistake". This is about the complexity of growing a new kind of distributed system where best practices are still unsettled. Specific commits and contributors being identified is part of taking this subject seriously. If you are above having your work questioned then you should not be contributing to a big critical part of open source infrastructure.

I still don't see a problem with this. Why should Junio not be responsible for the issues in his code? There is no shame in taking deserved blame. Project maintainers are usually pretty used to that, and they're typically their own worst accusers.

It's not like someone as storied as Junio, who has maintained git for as long as its been a serious project with applications beyond the kernel, risks being fired because he made a handful of questionable decisions. He is, after all, only human. Only the insecure fret over every shed of blame.

It is, in fact, considered rude to circumvent/bypass/ignore the original author by saying "the code was wrong" without first giving the author a chance to explain the rationale.

Ultimately, the point at which "naming" transitions into "shaming" in a technical discussion is a matter of interpretation and balance, but I don't think we need to completely remove considerations of code parentage from technical discussions, which you seem to be advocating.

That wasn't the impression I got. He didn't attack Junio just basically said why he didn't agree with the direction things are going with a fair amount of technical detail.

Probably wasn't worth calling out the maintainer by name (or the hyperbole in the title, but clicks!) but at the end he explains that reading a interview with Junio how Git evolves and isn't really designed.

Even has a solution to the Git problems he sees "easy git" (which I had never heard of).

Completely unprofessional and childish. I stopped reading the article after that.

This was posted on Redfin's official blog by a "Principal Engineer", which is even worse and reflects poorly on Redfin. Does Redfin shame engineers by name when things do not work out? If a higher up is reading this you should rethink your engineering blog ASAP.

But don't forget: "We're hiring!"

(sorry, it's a huge pet peeve of mine, every technical article has to be an ad as well)

Agreed. I found calling out the maintainer weird and awkward.

Did either of you read the section at the end entitled "You or I might have done the same thing"..?

That empty, rhetorical cliche doesn't mitigate the way the author calls out the maintainer in such an abrupt and unneeded fashion in the first paragraphs. The author hadn't even described the problem before blaming the person; instead, were just told that git has 2 self-inflected, deep "scars", and that a single person, and by implication, that person's poor decision-making, is to blame for those scars.

Naming the maintainer would make sense later on when the author purportedly tries to get into contact with Hamano but, spoiler alert, fails at it.

If that section was at the top of the post, there might be a very different reaction to it.

If anyone might have done the same thing, why call one person specifically in the first place? This just gives the wrong impression and makes that person more reluctant to make changes.

Especially in an article that advertises multiple times that Redfin is hiring.

"Come work with us! We'll only be sure to publicly humiliate if you make a technical decision we disagree with!"

The author makes the argument that these commits changed the direction of git, and "Thanks to these two commits, it's now a tradition." The author's argument is made more compelling by the fact that it was the lead maintainer that made these commits. Did he need to name the lead maintainer? Perhaps not. But doing so does not convert the reasonable argument to an ad hominem fallacy.

i took it as maybe an attempt to try to catalyse change upstream in Git.

i hope i have a commit so controversial someone blogs about it 13 years later. i'd be equally happy to respond with a defense or concession. :)

it struck me as an irrelevant fact- not an attack. so i can't help but wonder if you all aren't taking more offense than the guy who made the commit himself.

It's not just that he calls him out for it, but that he does it so early on the piece before any real context is given, including what the actual problem is. We're just told that git is severely fucked, and that the problems can be isolated to 2 commits, even though the author fails to make contact with the commiter to give him a chance to make a defense.

> Well, I posted a question on the Git mailing list to ask, but the Git mailing list is so noisy that I doubt that anybody will ever answer my question, least of all Hamano. But I can speculate as to why; if I were Hamano, I probably would have made the same mistake.

And no, posting to the mailing list, which the author himself admits is too noisy for the commiter to have likely noticed, is not a real effort to make contact given the severity and self-assured nature of the assertion, which suggests to me that the author is lazy in other ways that make his analysis suspect. Seriously, the author is so cocksure about the problem, and yet too timid to email Hamano, who is on Github and has a listed email address?

It's an appalling lack of basic courtesy, never mind intellectual curiousity.

(Author here.) Let me begin by noting that your comment, criticizing my courtesy, calls me "lazy," "cocksure," and "timid." Name calling is not compatible with the basic courtesy you're calling for.

Despite this, I'll respond to you with basic courtesy.

As a maintainer of open-source projects myself, I hate it when people email me directly with questions. I ask that everyone use only public channels of communication, if only because that way everyone can benefit from hearing the answers. In my opinion, I showed courtesy and not "timidity" by not spamming Hamano's personal inbox.

However, I recognize that not everyone feels this way, and so I have taken your point and I have emailed Hamano directly. (I hope he doesn't mind.) If he responds either on the git list or to me privately, I'll update the post.

There's also the broader context that naming people that way is a signature of the online callout culture, where the goal is shaming and humiliation. This is so common now that it's likely to be the default frame when people run across it.

Commits to git are public

Reply on news.ycombinator.com