[still_grokking]

What's wrong with just working on and when the changes finally look like they should just do a `git commit --amend`?

Or if the commit should for some strange reasons really never exist just move HEAD one commit back. You could even get the changes back by merging the "bad" commit back without committing the merge (using the `--no-commit` switch).

[brundolf]

I think you're demonstrating the original point

[still_grokking]

And that would be?

That Git is able to handle even completely weird requirements, like making history disappear?

[brundolf]

That doing even a simple a action often requires understanding multiple esoteric concepts, and knowing even more-esoteric commands/options.

[still_grokking]

Making committed history disappear isn't something I would call a "simple action". That's something that is almost never needed.

The common case it to amend mistakes. Git makes it very easy to accomplish that.

The other thing is: Git is conceptually very simple. There are almost no "esoteric" concepts. It's just a Merkle tree and some pointers to nodes on top of a very simple plain-text database.

My experience with people that have problems to understand Git is that most of the time those people never tried to understand how Git actually works. But everything (besides the concrete commands and switches, oc) becomes almost obvious when knowing the inner workings.

The main problem with Git is its UX.

I don't know anything of this stuff out of the top of my head! I have to look up the concrete commands or switches every time. But from the conceptual point of view Git is very easy to use. Because the underlying concepts are indeed so simple and straight forward.

[brundolf]

> The main problem with Git is its UX

The UX is exactly what we're talking about, yes

I have a CS background and I don't even know what a Merkle tree is without looking it up, and I'm sure after looking it up I'd have to do more digging/research before it gave me a clear mental model of how git works. I'm pretty comfortable in git at this point - I know how to navigate the space of normal-ish states - but that came after years of exposure.

For a person who's learning to code, who's expected to jump straight into GitHub as a part of their very first real project, the situation is kafkaesque.

[still_grokking]

I would not mix up the UX and the underlying concepts.

The concepts are very simple. The UX on the other hand is at least "sub-optimal".

> I have a CS background and I don't even know what a Merkle tree is without looking it up, and I'm sure after looking it up I'd have to do more digging/research before it gave me a clear mental model of how git works. I'm pretty comfortable in git at this point - I know how to navigate the space of normal-ish states - but that came after years of exposure.

That's exactly the point that I've tried to explain: People make their life substantially more difficult because they never learn the basics. This way Git keeps to stay guess work till the end of days.

The theory behind Git may seem off-putting when words like "Merkle tree" come up. I understand that.

But actually it's something that I could explain to a 12 year old in 10 minutes…

Instead of looking things up people chose to struggle for years and years, without ever having any understanding about the "magic" that happens behind the scenes. But without the theoretical knowledge Git is not really intuitive, that's true. Coming up with a "plan" how to accomplish something becomes than a matter of black arts. But it really isn't! Git is very straight forward. Really. Just take the time to look up how it actually works. Everything (besides the weird APIs) will start making sense than.