from Hacker News

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

by wolandark on 6/25/24, 3:07 PM with 55 comments

• by andrei_says_ on 6/25/24, 4:29 PM

  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.

• by viraptor on 6/25/24, 8:57 PM

  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.

• by purpleflashing on 6/25/24, 3:34 PM

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

• by practicalrs on 6/25/24, 3:13 PM

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

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

• by gary_0 on 6/26/24, 1:16 AM

  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.

• by morkalork on 6/25/24, 9:12 PM

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

• by throwaway211 on 6/25/24, 11:31 PM

  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.

• by palata on 6/25/24, 8:59 PM

  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.

• by muzani on 6/26/24, 12:03 AM

  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.

• by asyx on 6/26/24, 7:03 AM

  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.

• by bravetraveler on 6/25/24, 10:08 PM

  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

• by ilaksh on 6/26/24, 1:05 AM

  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.

• by znpy on 6/25/24, 11:47 PM

  > 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

• by ivanvanderbyl on 6/25/24, 10:14 PM

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

• by shrimp_emoji on 6/25/24, 9:11 PM

  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.

• by givemeethekeys on 6/25/24, 9:10 PM

  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.

• by devoutsalsa on 6/26/24, 6:59 AM

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

• by JoeyBananas on 6/26/24, 2:55 AM

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

• by nine_zeros on 6/25/24, 7:31 PM

  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.

• by powerapple on 6/26/24, 4:15 AM

  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.

• by aio2 on 6/25/24, 8:06 PM

  Dude, it's okay to say 'dick'

• by horsh1 on 6/25/24, 8:11 PM

  Latin should be okay.

• by brudgers on 6/25/24, 9:01 PM

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

• by pengaru on 6/25/24, 6:54 PM

  no

• by wizzwizz4 on 6/25/24, 8:41 PM

  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.