[mikepurvis]

git revert doesn't undo a commit though— it creates a new commit that undoes it. That might be what you want under some circumstances, but most of the time that I want to revert it's a commit I just made and haven't pushed yet, so I just want to pretend it never existed.

[pooper]

I don't know much about git but I just do

    git reset --soft HEAD~n 

where n is the number of commits I want to undo.

Known issue: can't undo all the commits.

[bombolo]

git reset --hard origin/master just deletes all your local work on the current branch.

[pooper]

I never want that though. If I wanted to do something like that, I'd do the git reset soft, followed by git stash, followed by git switch. I think this at least allows me to look back at it locally?

Git switch is also something I learned recently so sometimes I type checkout because of force of habit but I am trying to do better (even though I'm not sure what switch dies that checkout can't but don't want to get into arguments, just want to do things the prescribed way).

[chaorace]

The thing about git is that it's basically plumbing all the way down. In this case: switch abstracts over checkout, which abstracts over read-tree & checkout-index. The nesting doll just keeps going.

Because switch is built on top of checkout, there's no functional difference between the output of the two subcommands when used for the same purpose (assuming the presence of a skilled operator). It's strictly a matter of ergonomics and abstraction.

At the end of the day, as long as you don't fuck up, just do whatever best keeps you in your flow state.

[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.