[pas]

Thanks! Also congrats on 1.0!

Is there a FAQ that explains this? I sort of have an intuition for what does that ("prevent commutation of patches") mean, but I don't know how complete (or useful) it is :)

(I guess it has something to do with commit hashes depending on the whole chain of commits, so even if the diff between two commits is empty if they are not the same hash, they are not the same ... thing. But I don't really understand the practical implications of this. To me it seems like there's none. If two branches have the same content I'll treat them as equal. (And with some simple heuristics - like rebase is better, reverts are ugly - I'll pick the nicer one to keep. I don't really care how they ended up equal.

What am I missing?)

[pmeunier]

Practical implications: merges are 100% predictable and deterministic, this isn't always the case in Git, sometimes lines are shuffled around (look for "associativity" in the manual).

Also, you can actually cherry-pick.

And rebases are not a hack.