[juped]

> You’ll rarely review single commits anyway.

This is just because Github and its imitators are bad software - which isn't really git's fault. git and Linux practice only commit-level review.

> Many of my colleagues view using Git not as part of their core work but an inconvenient chore.

Many people don't care about version history, and ignorance of how git works (or adherence to superstitious rulesets) on the part of the people who do care provides them cover for trashing the history.

Many people don't care about code quality or maintainability. However, these people are more likely to be prevented from trashing the codebase itself than the ones who don't care about history are from trashing the history.

Commit history is just as subject to review as the contents of diffs.

[fuzzy2]

> git and Linux practice only commit-level review.

I don’t think that’s an accurate way to put it. AFAIK you just send in patch files. They create a single commit, yes, but I see it as equivalent to a PR. The rules of what can be in a single patch could be stricter than typical PRs on other projects, dunno.

> Commit history is just as subject to review as the contents of diffs.

I wish. Maybe I’ll work on a better team on the future.

[juped]

what I mean is, take any arbitrary patch thread off the front page of https://public-inbox.org/git/ and look at how people review them. they reply to the relevant commit. if you reply to the cover letter it's not a code review at all, but a more general comment on the whole branch (e.g., "do we want this feature" or something).

you definitely don't send your branch as a single patch (unless it is small and really is best expressed as a single patch). if you did you would be asked to break it up.