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?
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.
This is a great advice! Thank you! I politely asked the contributor to rebase and translate the Chinese bits.
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.
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/
I also would not want localized commit messages in my repos.
Maybe I would forget to translate some things, in which case a friendly request to fix the oversight would be appreciated.
Please try to unbunch your pantaloons.
- 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.)
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.
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.
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
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.
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
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!]
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.
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."?
A tooling problem. I elaborated in my third paragraph. (Please provide substantial criticism.)
