Ask HN: Is it a di*k move to reject pull requests with non-eng commit msgs? | Hacker News Reader

Ask HN: Is it a di*k move to reject pull requests with non-eng commit msgs?

22 pointswolandark55 comments

Tl;Dr is it a di*k move to ignore or reject pull requests that use non-English languages in commit msgs even though the project is all documented in English and is not a local project?

I just noticed a pull request with 5 commits on one of my repos with Chinese commit msgs. Even though the author has added a commit msg in English, explaining what he has done, it still pisses me off that I can't navigate the pull requests in a sane way because I can't tell what they contain until I open them one by one.

What do you think, and what is the professional approach to sth like this?

View on HN

I would try to drop the “d*ck move” narrative from my thinking if I was you.

There’s a clear precedent, and a clear reason, to request the rewrite.

This has nothing to do with personalities and everything to do with the quality and navigability of the code - just make sure to communicate the whys with your request and word it politely.

Agree - there's strong precedent to English in the docs, and no localization branch presumably, so it's ok to reject if clearly explained. Something rubs me the wrong way with the question though, probably this:

> I can't tell what they [commits] contain until I open them one by one [because they are not in english]

I'd hope the diff does this for you, and I'd also hope you don't go solely on commit messages to see what they contain! If you're reviewing PRs you don't have to check each commit anyway. And I hope it's not true that if you're reading the commit msgs (instead of top-level change) and getting mad when they don't make sense.

It might be I misunderstand your question. At any rate, yes, ask for translation if you need it to be satisfied with the PR.

It would be no different from me doing a PR with commit messages in German. Imo, that would be disrespectful towards the maintainers. Even if I put an English translation in the body of the commit message, only the German message is shown by default and it requires an extra step by anybody trying to go through the commits to see the translation or to find a particular commit.

I agree. I dont think the language is the issue, do you?

Yes, the language is not the issue, the issue is that it isn't English. I wouldn't send a PR to some repository with Persian commit msgs. It just doesn't make sense. If it was a bilingual repo or something like that it would have be fine though.

> Yes, the language is not the issue, the issue is that it isn't English.

Take it a step further.

The issue is that the value of the commit messages has been lost or degraded because they are not understandable to the maintainers and development team.

The same issue would (presumably) be raised if it were in German, Caesar cipher, English in random alternate UTF characters, formatted in some weird way that substantially reduced utility, or even just borderline unintelligible English.

(And if that’s _not_ the case, then this _is_ an issue on your end and I’d say you’re in the wrong. Ignore the rest.)

I’m guessing you’re worried about coming across as a dick because in your framing this is veering into language, culture, and all sorts of other things where some sensitivity should be employed. It doesn’t need to go there, though.

The focus is the utility the messages provide, that you value that utility, and that this does not provide that utility. In that sense it’s no different than asking someone to update a PR to include documentation updates, add comments to their code, or something similar.

> I would try to drop the “d*ck move” narrative from my thinking if I was you.

This is a great advice! Thank you! I politely asked the contributor to rebase and translate the Chinese bits.

I think you're overthinking this. "Thanks for the PR. Could you update the commits to English, please?" Is all that's needed.

If the situation is pissing you off, that's a separate thing. Maybe you should slow down and consider why. Someone just gave you some of their free time, just not in a perfect way you expected.

They also made work and it is natural to resent work. Even work you enjoy is still work.

People are too easily pissed of by things that can be solved simply by communicating.

>What do you think, and what is the professional approach to sth like this?

I'd say this would be a perfect time to introduce or update your project's contribution guide.

You can develop your own rules or use some existing spec to standardize commit messages such as Conventional Commits: https://www.conventionalcommits.org/en/v1.0.0/

Thanks for the tip and the link. I added a section to the README about commit messages conventional with a link to the website you provided.

You can ask the contributor to rebase the branch and rewrite commit messages.

I also would not want localized commit messages in my repos.

Let's flip it around. Personally, I wouldn't submit changes with a bunch of English in it to a project that was primarily Chinese. I would feel like a jerk doing that. Instead I would make a best effort to translate everything into the project's language.

Maybe I would forget to translate some things, in which case a friendly request to fix the oversight would be appreciated.

It's absolutely valid to reject for non-English if you want. I've seen companies have to enforce that policy internally too before.

No. Your repo's in English. It's lazy of the contributor. I'm a Chinese speaker if that makes any difference which it shouldnt.

Is the repo in English, or Eng? Professional and unlazy is not to use so god damn many abbrs (/s) like "sth" or "msgs".

Please don't grind your axe on me.

Just continuing the "lazy" thread, I'm annoyed at OP, not you, throwaway.

HN has a max length of 80 for the headline. Yes, AFAICS the "-lish" would have fit, but not both that and the "esae". Presumably OP shortened down from the error "Over 80!"and just didn't happen to notice that they could have got away with shortening a smidgheon less.

Please try to unbunch your pantaloons.

And what's the character limit of the text field where he keeps using these abbreviations?

You already got used to them from the headline, so by then it's no problem. ;-)

Read the code:

- If you can understand it and it makes sense, feel free to rewrite the git history and accept the patch.

- If you cannot understand it, ask questions based on your understanding. Feel free to refuse the PR if it does not end up making sense for you.

The fact that the commit messages are not English don't matter at all IMHO: you are entitled to refuse a PR even if the commit messages are in English. What matters is whether or not you want to maintain the offered changes. And in order to do that, you need to understand the code.

That's a lot of work. It really depends why they are doing it in the first place.

That's the very basic job of being a maintainer. If you don't read and understand the code, you should just not merge it.

Nothing forces you to merge contributions. But if you do, do it right.

How big are the changes? Is this a huge new feature or some small fix?

My recomendation is to look at the code and secretly use Google Translate to see if they make sense. If they make sense, ask them to translate the messages, and then fix any typo of small gramar error before merging.

(Some mantainers like to ask to fix any minor error, but it's anoying for the contributor.)

The professional approach is to add the English requirement to the style sheet and ask them to resubmit it accordingly to the submission guidelines.

To be more polite, run it through Google Translate yourself and propose text that isn't broken English. Sometimes they're just terrible at English and are reluctant to translate it.

I wouldn't be surprised if the commits are just "aaaaaaaaaaaaa" or swearing in another language.

Rule of thumb in Germany is that everything code related must be in English for the simple reason that should you hire people that are not speaking German, they will have a much harder type getting into the codebase.

And that's for projects started in German companies for German users written by German.

The idea of contributing to an open source project that hasn't a single German sentence anywhere to be found and then adding German commit messages seems insane to me. I'd never even thought about this.

So yeah. Just tell him / her to rewrite the commit messages in English.

Distilled completely, they end up processed one by one, right? Triage is always a slog.

Putting up contributor guidelines would help [assuming they're missing]. Otherwise, I'd just get to sorting out the code/branches when 'most convenient' and carry on.

Most of my stuff gets zero attention. I can't be so picky

I can understand why someone who speaks little English would be tempted to try to avoid translating the commit messages in case you didn't care. Maybe they were just busy.

But it also does seem reasonable to be annoyed and want it changed. Also reasonable to be less than 100% sure about making them do that if you want to encourage contributors. But you should ask them to fix things you don't like.

I think the nice thing to do would be to just use "please" when requesting to translate the messages. And if they won't bother for some reason then of course you don't need to accept it.

> Tl;Dr is it a di*k move to ignore or reject pull requests that use non-English languages in commit msgs even though the project is all documented in English and is not a local project?

No.

> What do you think, and what is the professional approach to sth like this?

1. Be thankful to the person that made these commmits

2. Explain that comments in a language other than english are difficult for you to understand and will be difficult for other people to understand as well, in the future

3. Ask the person to re-submit the pull request with commit messages in english, warning that you'll have to reject the pull-request otherwise

I would politely ask the author to resubmit the PR in English to ensure a speedy review.

Everyone should use English. All technology should be in English, as it was in the beginning. Locales were a mistake and are a headache. Internationalization is a misguided boondoggle that enables a quagmire of fractured communication.

The vast majority of the world doesn't know English, why do you want to deprive them of technology?

I believe GP was joking.

I think something like at least a quarter of the world's population can at least get by in English, so while yes, there may be a majority that doesn't, that majority is far from "vast".

Simplified Chinese is the most efficient language, besides the 30 MB fonts. But there's no reason to use any font besides Noto Sans.

It depends. The mantainers can choose any language they like. I'm not sure but a part of Ruby was in Japanese and a part of Lua in Portuguese(Br) because the author were from those countries. (Perhaps only the email list? I don't remember the details.)

Anyway, I agree that it's easier to find contributor from all arround the world if the mantainer choose Broken English as the main language of the project. [Hi from Argentina!]

You could reject it with a nicely worded rejection message, thanking them for their work and explaining why it causes difficulty and how they can resubmit it with a fix and how the fix would make future contributors lives much easier.

Be kind and you just might find they’ll rewind what they had in mind.

Commit messages don't matter. They're inherently redundant.

I would think it is a d*ck move to base a PRs value on commit history instead of the final PR message that could be squashed and merged as one commit.

Personally I think we should have already live in an age of no barrier of communication. Machine translation is working well. I often click on "translate" button on Facebook, TikTok for comments in languages I don't understand. I think it is a problem for GitHub to solve, not you. So I would say, you can reject based on the fact that as a maintainer you don't understand the commit message, it is fair.

Dude, it's okay to say 'dick'

It was actually code for "dirk".

A dirk move is where you stab someone. Metaphorically in this case, I'm sure.

Prick works well for both uses. I once called someone a prick to say they were being a pain, then got temp banned because it means penis in the UK.

Nah, a dirk move is when you jet around the world and find strategically important historical (usually military) artifacts. Or possibly when you drink a lot of tea while solving holistic mysteries.

Every time I read "*" or "%@!" to self-censor words, I'm reminded how people continue to infantilize the internet entirely of their own doing. If it bothers you so much to write a word as it is, why not just... not use it? So ridiculous-looking.

YouTube and TikTok gain extra fuck-you points in this arena.

Latin should be okay.

If you think it might be, behave as if it is. Good luck.

I think, if you have this problem, your tooling is bad. There are broadly two approaches to git commit history: (a) it should reflect the historical development process; and (b) it should be cleaned up and pretty.

If you're taking approach (b), then the maintainer is responsible for rewriting commits (e.g. squash merge). If using GitHub, only the commit description given in the PR is used, and the "true" history is discarded, so it doesn't matter.

I prefer approach (a), but even something as primitive as gitk (from Git GUI) would let me browse the history you describe without issues. Provided that the merge commit is a summary in the project language, intermediate "true-history"-style commits are most useful as a mnemonic aid to the original developer, and secondarily as evidence for a retrospective investigation (for which you want as much primary-source data as possible: even if the author's fluently bilingual, translating risks losing valuable information).

The best approach, imo, is to be fine with this, and take measures to ensure that it does not impede your workflow. An acceptable, professional approach would be to add a contributor's guide, requiring that all commit messages have their first line in English.

If you're getting angry, that suggests you're doing something silly like relying on GitHub's useless web view.

Different people using different languages is a tooling problem now? This is peak HN.

> Even though the author has added a commit msg in English, explaining what he has done, it still pisses me off that I can't navigate the pull requests in a sane way because I can't tell what they contain until I open them one by one.

A tooling problem. I elaborated in my third paragraph. (Please provide substantial criticism.)

> There are broadly two approaches to git commit history: (a) it should reflect the historical development process; and (b) it should be cleaned up and pretty.

Can't you have both? Like, before you squash-merge your feature branch into main, you branch a new "feature archive" branch off it -- shouldn't that keep the more detailed history in that branch, even as the original feature branch gets rewritten? Then you'd get both a nice and pretty linear main -- well, not exactly "linear", in the sense that there are still lots of "dead" feature-archive branches off of it, but the "clean history" club can just ignore those -- and the full commit history of each feature for more detailed spelunking. Hmm, suppose it depends on whether squash-merge deletes old commits or creates new ones to replace them; feels like if they're in the ancestry chain of an "archive branch" they should be preserved there.

___

Parenthetical:

> If you're taking approach (b), then the maintainer is responsible for rewriting commits (e.g. squash merge).

Do they really have to be? What if the project policy states "Only submit PRs with nice and pre-cleaned history."?

Reply on news.ycombinator.com