zlacker

>>flexdi+(OP)
Every time I see one of these nifty git tricks or workarounds I find myself wondering, “why not just use jj?”

You get a nicer, significantly simpler interface. You don’t need any tricks. You don’t have to google how to work yourself out of a bad state, ever. And you get near-perfect git compatibility (ie you can use jj on a shared git repo, doing all the same things, and your teammates won’t know the difference).

I’ve wondered if there is a psychological thing here: someone who spent time memorizing all the git nonsense may have some pride in that (which is earned, certainly), that introduces some mental friction in walking away???

>>swaits+JWe
This particular tip is basic. It just describes how to copy changes from one branch to another with one kind of rebase. But there's always someone who is learning git for the first time and may not even know how it's used.

Git is simple enough and has features and capabilities that jj does not have. Contrary to popular belief, git is not hard to use. I refuse to use any "simpler" system that is slower or less feature-rich than git. I don't even want to learn another commit graph model, because git's model is very good. About 95% of what people like yourself call "git nonsense" consists of useful features that many people would be annoyed to not have.

I believe that a large number of git or general VCS users have no idea about commit hygiene. They have not had to cherry-pick or edit commits, and have no idea what to do about conflicts. To people like that, git's features and methods will appear especially foreign.

I looked over jj specifically many moons ago and concluded it would annoy me and not function at my job. I forgot what the reasons were. One reason was most likely because I need submodules and worktrees to work. I just looked at its FAQ, and saw a bunch of nonsensical new terms as well. Nothing is more compatible with git than git itself, and I am very satisfied with how well git works for me.

>>wakawa+G0h
submodules aren't native with jj, you use git commands to manage them, and it works fine. Eventually there'll be some sort of native support.

worktrees are called "workspaces" in jj, but are the same.

A lot of people find jj easier to have good commit hygiene with, and find it simpler and more powerful, not less. But that said, if you're happy with git, you should continue to use it.

>>stevek+a3h
What is the most useful feature of jj that you think git doesn't have?

>>wakawa+Wih
I can pick only one? Perhaps automatic rebasing then, i.e. that all descendant commits and bookmarks (branches) are automatically updated when you rewrite a commit, e.g. by amending into it.

>>martin+Ivh
I don't think I would want to rewrite all branches based on rewriting one of the ancestors of those branches. This only makes sense for local branches, and I just never have such a set of branches. Most rebases are to get ahead of upstream work, and I can't rewrite that. The rest are to rewrite commits that I made, and I collapse all those commits down periodically anyway. In the rare case I might be able to use this feature, rebasing all the other branches (realistically, probably like 1 or 2) would be easy enough to do manually with the feature described in this post. Rebasing and touching up commits is very easy with git interactive rebase. There are also features to automatically reorder commits with, e. g., `git commit --fixup` and `git rebase --autosquash`.

If you have others in mind then go ahead lol. I was just trying to make it easy.

>>wakawa+ICh
> I don't think I would want to rewrite all branches based on rewriting one of the ancestors of those branches. This only makes sense for local branches, and I just never have such a set of branches.

Yes, it's only meant for local branches. When I used Git, I had a script for rebasing dependent branches. I remember that a coworker had written a similar script.

I think jj is generally more useful for people like me who often have lots of independent and dependent work in progress. If you mostly just have a one review at a time, there's much less benefit. Perhaps I would say that `jj undo` might be the most useful feature for users with simpler development (yes, I know about the reflog, but see the video I linked to in the other message).

>>martin+RDh
I think you're right about people having trouble with `git reset` but it's really not that hard. There is also the newer `git restore` command which is somewhat easier. There are many individual functions which have an inverse, so the word "undo" might not be a good choice for git. You could make a `git undo` that does the `jj undo` logic with the reflog very easily. I'm not sold on the simplifications yet but to be fair I'm not trying to learn it either lol.