Ask HN: Is it a di*k move to reject pull requests with non-eng commit msgs?
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?
56 comments
[ 3.4 ms ] story [ 118 ms ] threadI also would not want localized commit messages in my repos.
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/
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.
> 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.
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.
This is a great advice! Thank you! I politely asked the contributor to rebase and translate the Chinese bits.
A dirk move is where you stab someone. Metaphorically in this case, I'm sure.
YouTube and TikTok gain extra fuck-you points in this arena.
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.
A tooling problem. I elaborated in my third paragraph. (Please provide substantial criticism.)
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."?
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.
- 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.
Nothing forces you to merge contributions. But if you do, do it right.
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.)
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!]
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
Please try to unbunch your pantaloons.
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
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.
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.
Maybe I would forget to translate some things, in which case a friendly request to fix the oversight would be appreciated.