[whatevah5982]

As a single developer or a team working in the same organization you can ignore this property, however in a distributed VCS it is pretty much a defining and essential feature.

Guaranteeing that the history is the same is paramount to ensure that the same operation on two repositories which are _supposed_ to be identical will yield the same results.

This is what allows you to merge back history from a forked repository over which you have no control with confidence.

You don't necessarily need that property, true. You also don't necessarily need to make it mandatory. However if you want to play in the distributed VCS game, you'd better have something equivalent that can give you the same guarantee.

[a1369209993]

> As a single developer or a team working in the same organization you can ignore this property,

That was my point; by fiddlerwoaroof's logic there would be no compelling reason for single developers or cooperative teams to use git (besides cargo-culting the linux kernel devs). But in fact there is such a reason - the graph structure I mentioned, or rather the sophisticated operations based on that structure.

> This is what allows you to merge back history from a forked repository over which you have no control with confidence.

When merging commits from a source repo into a destination, for each commit, either:

a, it doesn't already exist in the destination, in which case you have no way of knowing that the previous-commit data is correct, because while tampering would change the commit hash, you don't know what the old hash was because you've never seen the commit before.

b, it does already exist in the destination, in which case you have a perfectly good history for it already and (assuming the source disagrees, otherwise you'd just always ignore it) can either simply ignore the source's idea of where it came from, or (probably more usefully, but it depends on how you're organizing things) alert the user that they have two conflicting claims about the history of the commit, and ask for help the same as any other not-auto-resolvable merge conflict.

Git effectively treats b(≠) as "tell the user the source repository is horribly broken because its commit hashes don't match their content", but it fundamentally can't give you confidence about the parts of "history from a forked repository over which you have no control" that it hasn't seen, and including history in commit hashes isn't necessary for noticing that the parts it has already seen before don't match up.

[fiddlerwoaroof]

I never said it’s the only reason to use git. However, it makes things like SOX change control easier because you can pass the commit ID around as a shorthand for a known state of a repository that is, practically, a UUID.

Similarly, as a single developer, it means I can verify repository backups by checking that all the repositories have the same branches and that the head of each branch has the same commit ID.

[whatevah5982]

> a, it doesn't already exist in the destination, in which case you have no way of knowing that the previous-commit data is correct, because while tampering would change the commit hash, you don't know what the old hash was because you've never seen the commit before.

In a fork we validate the common ancestry. This is used so that you can diff from the last known commit to the current point in absolute terms instead of relative.

> b, it does already exist in the destination, in which case you have a perfectly good history for it already

Unless it has been rewritten. Which, in git, we know can also happen by mistake. In such cases we can argue that you can diff the entire source tree and narrow it down the point where you believe the history path diverges and spot the changes youself, but git makes it a little bit more convenient.