[syntheweave]

This is the comment I wanted to make. DNS is one of those technologies that has a simple explanation - "it's indirection" - with consequential ramifications that turn it into someone's job. Most people will not interact with it often enough to know how to perform the job, so they remain hesitant and try not to do anything at all with it, because it burned them once before.

Git is analogous - most uses of Git are formulaic, and the underlying concepts are simple enough - but actually accessing the right lever to pull when disaster strikes is unclear and hard to experiment with. I'm in this latter category with DNS: I get it at a high level, but it's like a student who has only done the simple example project.

I'm of the opinion that we're at a good moment to redo the things DNS does with better separation of concerns by going towards "put those records on a blockchain, streamline it for known applications, reframe the hard problem around bootstrapping access to on-chain data". It's already been explored in varying degrees(e.g. Ethereum Name Service, Symbol namespaces) but it's not really something that has to be the monopoly of any specific chain.

[cyberax]

ANYTHING that has the word "blockchain" is automatically disqualified from pretty much any real use.

In particular, pretty much nobody wants to trust DNS names that can cost hundreds of millions to blockchain. Because if you lose (or compromise) your private key, then that's it. The domain is gone.

With regular DNS this would be solved by a couple of irate phone calls to registrars. At worst, via a court case.

[zx8080]

> Git is analogous - most uses of Git are formulaic, and the underlying concepts are simple enough - but actually accessing the right lever to pull when disaster strikes is unclear and hard to experiment with.

Would you mind sharing some examples of hard-to-recover git related disaster? I ask because I previously worked with applying hundreds of patches on top of chromium (yes, Opera). This resulted in __multiple__ merge‐conflicts. However not anything close to what I would call a git related disaster. Anything could be undone nicely.

What is important is that git is very verbose by default. It guides through not only a repo current state but also options user has.

I've met many developers not caring to read any of a git output and then claiming git is too complex and git broke their repo and it's "too complex to use". I'm sure it's not the case for you though.

So I'm just curious what kind of disaster was mentioned above.

[unmole]

> I've met many developers not caring to read any of a git output and then claiming git is too complex and git broke their repo and it's "too complex to use".

This a hundred times over.

[AlotOfReading]

Not OP, but I've encountered a few situations where the solution was modifying .git/ manually. The one that comes to mind was having two branches with names separated only by case on a case sensitive system, and then checking out both on a case insensitive system.

[pmontra]

Wouldn't be easier to rename the branches on the case sensitive system (a throw away Linux VM would do), push, pull?

Of course if the solution is editing .git/config, that's even easier, but it probably takes more than that.

[AlotOfReading]

It's been awhile so my memory is fuzzy, but this was at a windows-only shop back before WSL was a thing and getting a VM involved an annoying months-long requisition process. I think the repo state was actually corrupted too, so pull may not have been working.

[zx8080]

> I've encountered a few situations where the solution was modifying .git/ manually

Would be very interesting to know the purpose of modifying .git/ manually.

[da39a3ee]

> and hard to experiment with.

Just on the topic of git: git makes it extremely easy to experiment! But far too many people, including those writing tutorials and blog posts, don't understand this. Whenever you're in doubt, just commit your work and make a temporary branch and switch to it. Then you can mess about with merging and rebasing and dealing with the conflicts to your heart's content.

This should be among the very first things we teach to new git users.