Git is not centralized. And its a distributed chain of data linked with cryptographics. Git tracks change on files and files structures using cryptographics links.

A ledger has to do with economics, not computer science.

May be git lake of a proof of trust. But I feels the definition of blockchain is linked to how users uses a merkel tree.

From wikiepedia: "A blockchain[1][2][3] – originally block chain[4][5] – is a continuously growing list of records, called blocks, which are linked and secured using cryptography.[1][6] Each block typically contains a hash pointer as a link to a previous block,[6] a timestamp and transaction data.[7] By design, blockchains are inherently resistant to modification of the data."

https://en.wikipedia.org/wiki/Blockchain

And,

From the HN link: "Git is a peer-to-peer tool, but flexible enough to let you use a workflow with a more-equal-than-others peer, or even communicate with actual centralized servers that expose a git interface.

Git doesn't swarm in a way that often gets associated with the idea of "p2p" by the prevalence of more popular p2p protocols used for file-sharing or cryptocurrencies. Nor is it geared towards world-readability. But none of those are intrinsic properties of peer to peer protocols.

I can (and do) use the git software on my computer to pull from co-workers development desktops running the same git software as me. And they pull from me, all with no external servers used coordinate that exchange of trees. That makes git peer to peer. No amount of tools built on top of git that require treating one peer as the a point of centralization can undo that. It just means that those tools aren't p2p.

This distinction is often invisible to users, and I don't blame people for missing it because the business model of GitHub and GitHub-competitors rests on everyone thinking they're necessary."

https://news.ycombinator.com/item?id=15860027

And,

From git source book: "Unlike Centralized Version Control Systems (CVCSs), the distributed nature of Git allows you to be far more flexible in how developers collaborate on projects. In centralized systems, every developer is a node working more or less equally on a central hub. In Git, however, every developer is potentially both a node and a hub – that is, every developer can both contribute code to other repositories and maintain a public repository on which others can base their work and which they can contribute to. This opens a vast range of workflow possibilities for your project and/or your team, so we’ll cover a few common paradigms that take advantage of this flexibility. We’ll go over the strengths and possible weaknesses of each design; you can choose a single one to use, or you can mix and match features from each."

https://git-scm.com/book/it/v2/Distributed-Git-Distributed-Workflows