|
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. |
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."?