My brain immediately jumped to "but you can just git reflog and then copy the state you want to revert to and then git reset --hard <commit>", but not only is that not simple or obvious, it isn't even correct, since a commit or amend operation can be performed with only some of the changes staged, and a hard reset will wipe out anything unstaged. Ah sigh.

So yes, in short I agree.

Well in that situation you can stash unstaged, reset, then pop. But that just reinforces the OP’s point. Not the most ergonomic or discoverable path for something that should be simple to do.

git reset HEAD@{1} should do the trick to "uncommit" and keep uncommitted changes in the absence of conflicts. (I may be missing some edge cases.) It does however unstage changes.

Right and it is not obvious: git reset HEAD@{1} .

Right, if you grok the git model then this makes sense. But if you just want to use a tool without learning how it manages state, git is a pain.

Isn’t this just git reset —soft HEAD~1?

Put my stuff from the last commit back into working directory?

Very unintuitive (soft?) and I’ve just memorized this for the past 10 years.

Maybe I'm misunderstanding, but isn't this what `git revert` is for?

Harder with an amend due to having to get the difference of commits within the reflog, sure.

That’s actually not what git revert does, hence the poor usability of its API.

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.

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

I think you're demonstrating the original point

And that would be?

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

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

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.

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

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

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.

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

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

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.

I've been using lazygit[0] for a while, which might not be what you're looking for but I enjoy it a lot.

[0]: https://github.com/jesseduffield/lazygit

Using lazygit has improved my usage of Git so much! There is a nice video from the author that introduces a lot of its features.

[0]: https://www.youtube.com/watch?v=CPLdltN7wgE

I tried it, but I found it too radical a workflow change, and it wasn't intuitive for me. Loved the concept though.

10 years? Maybe try RTFM. Then a few command aliases and you're on your way. Takes way less time.

Lol. Orrr we could just do things sensibly in the first place.

I always chuckle when things like “sensible”, “user-friendly” or “sane” get thrown around as if they are anything more than that person’s opinion.

When are developers going to learn that they actually have to learn and familiarize themselves with preexisting systems, instead of endlessly reinventing them, and that there is no such thing as the perfect system?

Nothing is perfect, but some things are clearly better than others - hence why we’re nearly-all using git rather than "learning and familiarising ourselves" with CVS :)

Fair point, but it is not clear to me that Sapling is better than Git. I haven’t seen anything in its docs or in the comments here where I haven’t thought of a way to do it with Git.

I wonder what the cost benefit analysis would be: how many developers hours have been expended building Sapling so far, vs a list of things it can do that Git cannot.

And I guess it bears repeating that I’m interested in possibility and not aesthetics.

Given that they’re both open source and can be customised using turing-complete languages, the only limit to possibilities is how much effort you’re willing to put into customising them. Even CVS has the possibility of working as a distrubuted system if you wrap it up in enough layers of hacky shell scripts ;)

Having done quite a bit with both mercurial (which the sapling CLI is based on) and git, I find that the mercurial approach has a lot more sane defaults, is generally less effort for the same results, and has a lot of quality-of-life improvements — like git has the possibility of doing interactive commits with `git add -i`, but sapling's interactive-commit interface actually makes it usable.

The last thing I want to do is learn a new source control tool. For this to occur, it truly needs to be 10x better and not because someone isn't motivated enough to read the manual.

With how well git has worked for me, I suspect I'll use it for the rest of my career.

> where I haven’t thought of a way to do it with Git.

With git one can do "everything" true, doesn't mean that I want to teach everybody first what a DAG is and how one can manipulate that using git commands, but want to have something simpler. And yeah, git became a lot better over the years, but the plumbing still shines through in many places with inconsistencies.

Understanding a DAG becomes fundamental very quickly when trying to understand how distributed version control works. I would argue the opposite, that the internals are actually very reasonable and generic but it's the porcelain that has made some poor UX choices.

GitHub’s success was in part due to it making Git interface’s bareable. Imagine an UX so bad it generates a whole industry.

Lol wut. Github's success is in being a remote code repository.

So your claim is that GitHub would be equally successful if their website was just information about how to push to a git remote hosted by them?

SourceForge was pretty successful back in the day and they were pretty bland compared to GitHub.

GitHub's UX is so incredibly terrible. Pull Requests are horrible -- even mailing lists are better and that's impressive.

GitHub's UX is so bad it has indeed generated a whole industry of out-of-band review tools.

I don't think this is true. GitHub (the website) became very successful with virtually no feature overlap with the git CLI. I suppose you could say that GitHub pull requests and forks are a replacement for git's built-in email-based workflow, but that's not really what people complain about when they say git is hard to use (and it's not like the other DVCSes had obviously better solutions).

Forget the CLI. VSCode implements a ton of git features as commands, which can be bound to any keybindings. For me this is way faster than CLI, as I don’t even need to leave my text editor - I have it set up chorded, so AltG followed by P,U,C,Y, will push (actually sync), pull, commit, undo, respectively. Two keystrokes beats any CLI interaction I’ve seen.

(Disclaimer used to make VSCode)

because doing a commit with one keystroke is a good thing? i think it isn't - i like to consider things, rather than program like a hyperactive cockroach

You still gotta type the message.

I think the original poster was referring to staging the commit as their "thinking" step, not composing the message.

Personally, my workflow is to make many changes, then use `add -p` and `commit` to create a series of small commits. While staging, you might decide that you don't want to commit some bit of code and `restore -p` to toss it away.

I think your workflow would work well if you see commits as "development checkpoints" rather than semantic patches. It's not an invalid workflow, just a different one.

I'm sure you could configure VSC to be analogously ergonomic for any git workflow. But people who are comfortable with git and their shell of choice tend to develop comfortable workflows in the terminal as well.

For what it's worth, you can do similar to "add -p" in VSC by using "Next Change" to scroll through a file in the diff view and adding hunks with individually with "Stage Selected Ranges".

It's a little slower than "add -p" but serviceable. Having editable diff in the diff view is really nice though.

Taking time to consider things is good; but that doesn't mean you're better off with slow tools.

If developing has some loop like "consider -> implement -> evaluate", then the quicker you can implement it, the more budget you have for considering the problem.

I agree why should I switch from editor to terminal to do a commit. In WebStorm it is Ctrl-K plus adding the commit-message.

Most people's objections to git ergonomics is not that the commands are slow to type. VS Code exposes the exact same operations on the underlying repository as the CLI, and it's those operations that critics say are hard to understand and cumbersome to use.

The parent said:

> This looks incredible. A simple command to uncommit or unamend makes you further realise what a disaster the Git CLI is.

I said that simple command already exists in VS Code. Yes it can be done via CLI, but not as simply as in VS Code. Not sure what your claim is.

What is the unamend command in VS Code?

dude, vscode git interface is ... not really good. I really continue to keep a copy of eclipse around just to use the egit client. That is a good UI ihmo

I'm talking about the available commands, the UI is purposefully minimal.

I used to use Gitsavvy in Sublime, and honestly it was much, much better than what VSCode offers so far.

before building a new git, there just could be a new git command, i do not know like, undo for example.

just they build one for switch.

i hope they build a migrate one, where you can switch to new/other hashing standards.

I don't blame git, I'm mostly surprised about the social inertia regarding improving it. But like programming languages, pressure accumulate until it's released, I'm sure sapling and similar will make people want to try new things and git will soon catch up.

The social inertia point is an interesting one. It seems like in some areas, like JavaScript frameworks, there is a ton of inertia for change; in other areas, like git, there is a ton of inertia for stasis. Why is that?

Writing the umpteenth Javascript framework might be good for your career. It isn't hard, in fact, it is so easy a multitude of javascript-only developers attempt it on a regular basis.

Occasionally one takes off. Really just a function of how many friends the author has, their stature in "the community" and/or their aptitude for creating cute marketable landing pages.

There is a multitude of people capable of jumping in with hot takes explaining why the new framework is superior/inferior, tweets, blog posts, courses abound..

In contrast re-inventing git is hard. Few people can wax poetic about the differences between alternatives. Even fewer can come up with a new one. The audience is far smaller not to mention skeptical. Less profit in it.

Rather the difference between a new age cult/mega-church and the Catholic church.

I honestly don't know. For some reason, with JS frameworks, everyone seems to agree that improving ergonomics is a good thing. New methods are added, old ones are tweaked, constantly improving the developer experience.

But with Git, every conversation about improving the CLI has 50% of the participants claiming that the other 50% are just too stupid to use it, and that the CLI is brilliant.

Check out jj, it's made by someone who works on Google's source control

https://github.com/martinvonz/jj

I have been looking for something like this for so long!

I got 90% of the way there with a lot of git aliases. The other 10% is constraining your workflow and reasoning about what state each of your commands leaves the git tree in.

Admittedly this might not help since it is not CLI, but spend some time this weekend with Emacs and magit. You don't have to use emacs for anything else, just the magit client. It will transform your git experience.

I did something similar for years with Sublime and Gitsavvy. But I couldn't stop Sublime updating itself from time to time, and it kept breaking Gitsavvy, and it got really tedious to try to fix it.