A commit stores information about the state of the whole repository (in hashes). A patch is stateless, just describing what operations you do on the repository.

A commit stores information about the state of the whole repository (in hashes). A patch is stateless, just describing what operations you do on the repository. One confusing thing for git users is, git represents a number of commits (but not all types of commits) as patches. Two differences: - Cherry picking is possible, but when you cherry pick twice from the same branch, you get conflicts with commits, because cherry-picking change their identity. With patches, this works just as expected. - Merging can be made associative with patches, not with commits. Concretely, in git, if Alice and Bob add lines to a file, even when there are no conflicts, Alice's new lines can be merged in the middle of parts added by Bob, even though she's never seen these parts. Even worse, there is no way to tell when this happens to you (git doesn't say). "Associativity" is the mathematical property that this never happens.