[wakawaka28]

>Like what? Perhaps we can improve it.

I'm sure it is stuff that makes sense to a jj user. Since I have not read the manual, it is nonsense to me. I'm just drawing attention to the fact it's a different set of non-obvious terminology and features as compared to git. I'm sure anyone who read the manual for either tool could figure it out. The trouble with git is that people don't read the manual, and hardly try to do anything with it, then loudly complain about it being tricky. Anything as complicated as version control is going to be tricky if you don't read the manual. I don't think making another tool entirely is the right solution. Perhaps a different set of git porcelain tools could help, or some git aliases. Maybe better documentation too. But some people just can't be pleased.

[martinvonz]

This seems to be a common misconception, that many jj users don't understand Git. Most jj users I know were pretty good at Git as far as I can tell. Perhaps you'll find this recent video where Scott Chacon talks about Jujutsu interesting: https://www.youtube.com/watch?v=PsiXflgIC8Q. Scott is a GitHub cofounder, author of Pro Git, and now runs GitButler.

> I don't think making another tool entirely is the right solution.

I considered making the changes to Git but the changes I wanted to make would make the UX so different that it would basically mean introducing a whole parallel command set to Git. I figured it would take ages to get Git to that state, if I could sell the ideas to the Git community at all. By the way, the video above talks about an proposed `git history` series of commands inspired by Jujutsu (also see https://lore.kernel.org/git/20250819-b4-pks-history-builtin-...).

[wakawaka28]

Well, if I had to guess, many current jj users are git veterans who are tired of watching git noobs struggle. The other segment is the git noobs themselves, who never really bothered to learn git and have a deep aversion to reading the manual and doing basic experiments. Just a guess, though.

I think I saw Scott Chacon talk about his git config file and advanced git features. Whoever it was, it mentioned GitButler. That was a good talk. I would certainly expect someone like that to have a lot of interest and expertise in git. But it seem to me that there is also a potential commercial angle to making a new/alternative VCS.

I looked at the mailing list entry you linked to about `git history` commands and thought to myself, it sounds all wrong and redundant. `git history` sounds like too broad of a name for one thing. I'd want to have it be `git <verb>` instead. All the operations listed can be done with rebase:

- `git history drop`: Instead, rebase interactively and drop one or more commits.

- `git history reorder`: Interactively rebasing makes this work already.

- `git history split`: Insert a pause in the interactive rebase. Do a soft reset or something to the previous commit, and use `git restore` to unstage the changes (there might be a more efficient way to do this in one step, but idk). Then, do `git add -p` to add what you want, commit, as many times as you want to split the patch. Then continue the rebase.

- `git history reword`: There is a reword option in interactive rebase mode, and also a fixup-like option to do it as well if you want to postpone the rebase.

- `git history squash`: Rebase can do this now in multiple ways.

Rebasing is not that hard. It is the Swiss Army knife of VCS tools. Once you realize that you can just break in the middle of a rebase and do nearly anything (except start another rebase), the world is your oyster. We don't need to spam people with many more single-purpose tools. We need people to understand why the way things are is actually pretty damn good already, if only they read the manual.

[eddd-ddde]

> Rebasing is not that hard.

No, but it takes like 5 manual operations to do something as simple as amending my changes to a commit that's 3 parents before my current HEAD.

There's simply no excuses for git being this unusable for the very simplest operations I do day to day.

[wakawaka28]

Amending a commit behind HEAD is not a simple thing in general. You can have conflicts. When it can be done simply, it can be done in 2 steps with git (or less than 2, since you can amend lots of commits with one rebase). What are the 2 steps? After adding what you want, here they are:

- `git commit --fixup HEAD~3`

- `git rebase --autosquash HEAD~4`

The "less than 2 steps" part comes from fixing up more than one commit having no conflicts before the rebase. It is very common to want to stop or run test scripts at various points in the newly modified history, and rebase can trivially help you automate that (but only if you want).

Rebasing literally just does a sequence of steps in the order you specify. You can make those steps complicated, or not, without learning yet another tool. The complexity that is in the rebase tool is practically all necessary.

After using git for many years, I realize now that a lot of thought went into its design. The way it works, especially with the rebase tool, is superior to having a dozen single-purpose tools.

I don't think this particular thing is against the UNIX philosophy either. All of these operations are intimately related just like the operations that a FTP client might do. I can just imagine someone like you looking at FTP or rsync, and saying "This can be 20 different commands! Why don't they make my particular use case into its own command!" There is a place for that kind of logic, but all of the things jj supporters have proposed to me are way too niche to have their own separate commands. My commit edits are complicated, and `git rebase` makes them super simple.

[martinvonz]

Maybe you know this already but it's `jj squash --into @----` whether there are conflicts or not.

[wakawaka28]

I didn't know that, but I'm not surprised that this is possible because jj allows you to defer conflict resolution. I for one prefer git's step-by-step rebase model that makes you address conflicts at the time of the rebase. If you aren't ready to address conflicts, you shouldn't be mucking around with the commit history yet. Also, if you turn on rerere, then you can also (usually) avoid fixing the same conflicts multiple times.

[martinvonz]

The author of `git history` is a GitLab employee and prolific Git contributor. I think he knows how `git rebase` works.

[1718627440]

I think the issue that wakawaka28 has and I also have is, that I don't think we should have lots of "wizards" for specific high-level operations users want to do. Then we will only end up with hundreds of commands, that all do slightly the same. Also it will train (new) users to complain about adding yet another command to do what they want, instead of letting them learn how to combine the already existing commands.

What we should do instead is provide a bunch of primitives, that as high-level are as possible so to not end up with duplicate commands, which is what git does currently. `git history` as a name is somewhat pointless, since the whole point of git is to produce and modify the history. In that sense `git history` already exists, it is called `git`.

I think the issue newbies have is not that git commands are hard per se, but that they don't think in terms of modifying the graph yet, or that they don't know which primitives are available.

[steveklabnik]

For what it's worth, I mostly see jj as being to git what you describe in your first few paragraphs. That's why I like it so much.

[wakawaka28]

That makes his decisions all the worse and in poor taste IMO, because he ought to know that these use cases are well-covered already. Furthermore, I'm not talking to him. I'm talking to anyone who thinks that his patch was a good idea. I am not going to be dazzled by brand names in this conversation lol.