[tscs37]

It is a blockchain is you don't merge since you have a commit pointing at a previous commit, (block points to block), merges point to two parents but Ethereum has that almost with uncle blocks.

The commit log of a repo is almost certainly a blockchain, which is why I mentioned "to some extend"

[jacquesm]

You are simply wrong.

Think of a blockchain as only one strand (say, the leftmost strand, from a leaf all the way to the root) of a Merkle tree. Think of a git repository as the whole tree. So no, they are not equivalent.

If they were there would never be a way to have more than one branch depend on a previous one.

[tscs37]

As mentioned, the git commit log, not the entire repo, which is more organized like a merkel tree, though that is only really the storage.

The commit log is a strict DAG, if you don't have any merges, it is a strict blockchain, otherwise it gets fuzzy but is close enough.

I never said it's equivalent but that is what a blockchain is; "A blockchain [...] is a continuously growing list of records [...] which are linked and secured using cryptography."[0]

This doesn't mention "Can't be a merkle tree" for one, but also doesn't mention "can't consist of branches which merge again" or "requires proof of work" or "must use signatures" (cryptography refers to the hashes normally but can refer to anything else too)

Git also acts like a blockchain, if you change the past (edit a past commit) you need to update all following commits for the new hash and their children hashes and anyone who has the repository must do a force pull, similarly to how Bitcoin rejects fork chains with less proof-of-work.

It might be worth mentioning that Bitcoin also uses MerkleTrees for storage as they are very good for quickly comparing sets.

A blockchain does not necessarily process financial transactions at all and I don't see why it must be a requirement.

[0]: https://en.wikipedia.org/wiki/Blockchain

[jacquesm]

"if you don't have any merges" -> so, not a blockchain.

What you are saying is that you can use git in such a way that you get something resembling a blockchain but - again, and it is getting tiresome - that does no imply equivalence between git and the blockchain.

I really don't understand why you keep arguing.

[tscs37]

As I mentioned, even with merges it still has the properties of a blockchain, just not the ones traditionally used by cryptocurrencies.

You still have blocks (commits) pointing to other blocks (commits). Some blocks just points to multiple other blocks (think the uncle system in ethereum, which is just exactly that; temporary forks that are still included into the chain)

[pests]

There is two definitions in play here for the word blockchain.

In the version you mean, how does the blockchain (git, or any other blockchain by your definition) respond when two valid blocks are canidates to be added to the end of the chain?

Is only one block the winner? How is this property maintained as the blockchain grows?

These are the questions and issues the blockchain others in this thread mean can deal with, while, for example, these questions don't exactly make sense for, for example, git.

[sirclueless]

Yes, only one block is the winner. It is whatever the maintainer of the git repository chooses as HEAD. This property is maintained by any number of out-of-band mechanisms such as Github pull requests and company-wide mandates never to "git push --force".

Seriously though, it just seems like a question of semantics. Is a blockchain just a specific sort of Merkle tree -- thus making Bitcoin a blockchain plus a distributed consensus protocol? Or does calling something a blockchain necessarily imply some consensus protocol already.

[tscs37]

The maintainer must decide which blocks are valid. That's just as much of a consensus algorithm as Bitcoin just not as distributed and decentralized.

[jacquesm]

I give up.