> Most people on small projects just want "checkpoint the current code in my directory and put a comment on it".

Interesting, that's definitely not how I use git. My current code is rarely in a shape that can be fully committed. It often contains additional stuff I did on the way (small bug fixes, TODO comments, debug printf statements, etc.) that I don't want in the commit. Very rarely do I type `git add .` Am I the exception?

With “git reflog” and “git reset” or “git checkout” one can undo any series of ill conceived squash/rebase/amend operations. There’s actually no need to rsync the work area in advance.

Try doing the same in any other source control system…

Mercurials lack of not permanent branches early on with the bizarre "we have a plugin for that" way of doing it showing up too late to change the decision

not to mention the early "just clone it into a new dir" answer before lightweight branching ...

https://github.com/jj-vcs/jj

On the off chance that you haven't already had this suggested to you on HN, I would suggest taking a look at JJ.

I use it in all my Git-underneath repos with `jj git init --colocate` (You can run that in a git repo and it will hybridize, or in a new folder and it will init and hybridize).

It doesn't have the staging concept, treating the working copy as just another commit (@), and to boot it snapshots the state of the tree into @ when you run any jj command, so you can use `jj op log` to see every intermediate state of your working copy at any time.

Commit is just `jj commit` with no staging mechanics, or `jj split` to 'split the working copy commits' (commit some, keep the rest in @).

I often want to "save" but not have a comment, and not ready to make it a clean commit that I want a comment on. That's when I stage, then I can see the diff and revert still. But ya, maybe I could adapt to not worrying about having a million commits instead of clean ones at points that make sense with good comments.

You can add everything and commit all at once in git, so you’re technically using staging but it doesn’t feel like it.

I stopped using it the first time I committed something I didn’t want to, over a decade ago, haven’t used it again since so I forget the exact invocation, but I think it was just “-a” or something.

Before it bit me though yeah, that did seem like a default I’d have preferred. Not any more.

I'm curious on the use of rsync in version control. What's the source and destination?

I haven't lost data to git in a long time and I never rsync anything. But it took a long time to get to that point.

Git is extremely predictable, but only after you thoroughly understand it. Until then, it seems to surprise you often and every time it happens you think you've lost data. Many times I've had collaborators who said "git ate my files" and I can usually get their files back in a few minutes. This makes them hate git because they cannot use it without having me on call, and they cannot be bothered to learn git thoroughly themselves because it's too damn hard.

I find staging useful even in small projects. I've been deliberately experimenting with jujutsu for the past year or so in various projects, and one of the workflow differences that I noticed most readily with jujutsu was the lack of a staging area. It took me a while to get used to that.