Distributed ledger data is typically spread across multiple nodes (computational devices) on a P2P network, where each replicates and saves an identical copy of the ledger data and updates itself independently of other nodes. The primary advantage of this distributed processing pattern is the lack of a central authority, which would constitute a single point of failure. When a ledger update transaction is broadcast to the P2P network, each distributed node processes a new update transaction independently, and then collectively all working nodes use a consensus algorithm to determine the correct copy of the updated ledger. Once a consensus has been determined, all the other nodes update themselves with the latest, correct copy of the updated ledger.

From your first link. This does not describe how git functions. Did you actually read the page?

The consensus problem requires agreement among a number of processes (or agents) for a single data value. Some of the processes (agents) may fail or be unreliable in other ways, so consensus protocols must be fault tolerant or resilient. The processes must somehow put forth their candidate values, communicate with one another, and agree on a single consensus value.

From your second this. Again this description does not match with git.

You’re right in that automation is not technically required; you can build a blockchain using git by having people perform the distribution and consensus algorithms themselves. Obviously that doesn’t make git itself a blockchain in the same way it doesn’t make IP a blockchain.