When it comes to Git, there is much to explain as it is something of a complex case, but no - it is still centralised, albeit weakly.

First of all, differentiating between Git and cloud services like Github or Bitbucket, which are very popular these days: the latter are clearly centralised, the former is still centralised in a form but not as much. The below text refers to the former concept only.

One could reasonably call a non-cloud-managed Git ecosystem "decentralised" in most aspects, but certainly not fully decentralised (and when it comes to issues of trust and consensus issues, 'decentralised' and 'centralised' have very little distinction at all. Only fully decentralised could be different, and that isn't possible to do). This may seem like splitting hairs in terms of definitions, but it's *very* important in this situation.

Almost every part of a Git ecosystem (let's say, a bunch of devs using their own setup) could be seen to be decentralised. However, it still has all the problems that supposedly decentralised blockchains do: what do you do if over half the devs want bad changes to be included? How do you decide which branches should merged and which not, how do you manage conflict resolution, etc?

That's still a human consensus problem, and therefore unsolvable. Obviously in this example there are other considerations like code quality (which relies on the assumption of all actors being benevolent), but if we think of the simple example of malicious consensus here, there's still no solution to that. Your only solution is that some of the devs have higher authority than the others; without this, you either end up with splintered software with many different maintained branches that never merge and become their own competing software versions, or you end up with software that goes in a totally different direction to what was intended as the original "group" has lost control of it, so to speak.

I'd point out here that the first result of failed consensus - splintered software - is exactly what's happened to every cryptocurrency. Every time a failure of consensus has occurred (usually due to dodgy transactions being validated as the result of an attack), the cryptocurrency ends up splitting into two via a hard fork. Bitcoin's had this several times, Ethereum's had it (Ethereum Classic was the original before it got forked), etc.

As such, even here, Git ecosystems count as 'centralised'. I can certainly agree that it's a very weak form of centralisation - much of the system itself remains decentralised - but it is centralised nonetheless. The main reason this problem rarely crops up in the example of version control is that unlike a decentralised cryptocurrency blockchain, Git ecosystems are mostly set up and used by people with motives for the system *not* to fail, and who do not have any ulterior motive to e.g. include bad code or code that is contrary to the purpose of the software, and so problems like malicious consensus rarely arise. In addition, most developers in a given git ecosystem are knowledgeable both about software in general and the project specifically, and as such trying to pass off bad code by making false claims about it would be much harder to do than it is in cryptocurrency transaction validation.

Setting up N repos that work independently doesn't equal a fully decentralised system unless it cannot fail (ie. it never needs your input in the event of a conflict). Partially decentralised it may be, but that counts for nothing when it comes to consensus problems.

-----

There is a consensus resolution phase in cryptographic ledgers; it's just not formalised. In Bitcoin it's 'done for you' (not really, you can still decide it by modifying your software), but in cryptographic ledger situations it's done manually by people checking if they agree with the ledger. For example, suppose an obviously malicious commit is made; the consensus resolution is in the form of people seeing the ledger, not agreeing with its contents, and deciding there is a conflict. The parallel nodes in the ledger are humans instead of computers; all Bitcoin really does, for example, is transfer the job of decision making from you to the software (which while convenient, is actually quite dangerous, since most people using it have no clue what their software is actually doing and it is subvertable). The periodic reconciliation phase again exists; it's just manual and done by humans instead of automatic and done by computers, but the same vulnerabilities exist.

As for blockchain providing an advance - no, it didn't. As stated above, the only change it made was that it delegated responsibility for validating new blocks from humans to software; that comes with serious vulnerabilities, especially in systems with many involved humans (each user mining and using Bitcoin) where most of said humans have little or no knowledge of how the system works. It's not even a heuristic, it's just a basic delegation and nothing more. It makes it *easier* to validate transactions automatically - but it does absolutely nothing to improve the security or validity of said transactions, which are the only two relevant points when it comes to something that is going to be used as a currency. Ease means nothing if the currency's system cannot be said to be secure.

"The reason we didn't is almost certainly because these ideas just aren't economically viable or even practical (like forcing ticket sellers to accept your cryptographic proof over their own records)." - Not exactly. That's one reason - there is no commercial incentive to make a "collectively used" system, but the other reasons are security and accountability.

Your only way to make such a system work is if it has "some" form of central authority (how else is it going to have laws enforced upon it? Are you going to prosecute every user of the system if it does something illegal?), and while that would still make it mostly decentralised, you'd then have the problem of figuring out what to do if malicious consensus allows e.g. invalid tickets to have cryptographic proof stating they are valid. The only reason any such distributed system would improve over existing systems is if you didn't have to check them, or if you had to check them so rarely that it saved costs over existing systems; you don't know when the system might be compromised, and as such you can't check less rarely. There's plenty of motive for those who would maintain such a system - that is, the users - to subvert it (let's be honest, a whole ton of music band stans would absolutely do that to get free tickets to expensive gigs).

This points to the primary problem of distributed systems like this: cryptographic proof is only proof if it has not been compromised (it's proof of existence, not proof of validity). Let's look at an example of how this can happen:

Suppose I am Bob. Alice, who is not a technical user, inadvertently reveals her private key somehow (perhaps by a social engineering attack, it could happen in a hundred ways really). I can then make a cryptographically signed message saying that Alice said I can have $100,000 for free, and when the receiving company gets the message, they confirm the message was written by Alice using Alice's public key. What do you do in this situation? Unquestionably believe that the message is true simply because it's cryptographically signed? Alice may not even realise the private key has been compromised, so you can't turn around and assume the message is dodgy.

This is the problem you face: cryptography like this only works if users are careful, which usually means successful distributed systems of this nature require knowledgeable, technical users. That's not plausible for mass systems where people handing over their credentials knowingly or otherwise is rife in just about every area you can possibly find. That’s why for most things we do on the web, you have a centralised server that stores your username and the hash of your password, so that in the event of someone compromising your credentials there is a failsafe such as resetting via your email or something else.

"The blockchain's idea of "all nodes contain all information, with a periodic consensus resolution phase" brings nothing to the table for any real-world application except cryptocurrencies, which are "currencies" built on air. (And as you point out, this is a mitigation of the Consensus Problem, not a full solution.)"

It's actually a worsening of the consensus problem, not a solution. It's a worsening masquerading as a mitigation - because it gives the false impression that the consensus resolution is reliable when it isn't, and that all actors are benevolent, which in this system is absolutely certain not to be true (there are too many non-technical users to take advantage of, and far too many motives).