[bayindirh]

The difference between git and svn is, svn is very fixed in terms of workflow. On the other hand, git allows many different workflows, and allows people to handle their codebases the way they see fit.

Of course, no tool is truly universal, and git frontends and alternatives leverage different parts of the underlying data structures with different trade-offs.

I personally never use rebase, and am a merge guy. I don't use a gazillion branches either, not because I'm afraid of them, but my mental model works like that. Some people squash commits, others rebase, etc. Everybody is different in their ways.

svn to git was a fundamental change and allowed new things to happen. jj on the other hand makes some workflows easier while others take the back seat. So I don't see jj as a git disruptor, but an opinionated alternative tool which uses git data structures as the backend.

[Certhas]

I agree that the change isn't of comparable magnitude. But JJ changes the user facing conceptual structure of version control. It unifies working directory, stash, index and commit, and replaces them with a single thing. And it shows that all existing git workflows can efficiently be constructed on this much simpler conceptual basis.

In my mind this demonstrates convincingly that gits conceptual model carries unnecessary incidental complexity. Within a fixed complexity budget jj absolutely does allow new things to happen.

I also don't really see any workflow examples that truly suffer under jj, so I don't think it's just another trade-off. It's a real substantial improvement. If it wasn't it wouldn't be making headway against gits network effects.

[bayindirh]

From what I understand, all these different places/things (working directory, stash, index and commit) confuses, and comes across unnecessary to some people. They want a simpler solution, and less mental load during version control phase of their software, that's understandable.

In my experience software developers come in two flavors. a) Developers who want to understand all the pieces they work with and have the desire to deep-dive into them b) Developers who write and commit code. They think that former part is their job and care about it. They don't care after it leaves their machine (in the sense of "I give box to machine it magically integrates").

IMHO, jj is very enticing for the latter camp, and that's not a bad thing. Not all of us are passion programmers/developers, and some are don't want to think about beyond their immediate realm. I respect these people. But, again, from my perspective, jj doesn't make sense for me. It's useful alright, but I actively use index, commit and stash very naturally. I might be good at understanding it because Eclipse has a great git integration which makes everything super workable and understandable, and I'd never change a power tool like git to something "push button, magic happens" class of tool.

jj might be very conductive to more complex workflows by removing some complexities, but unifying my stash, staging area and index is not something I want to be dome to my workflow for example.

Some trade-offs make great headways into networks because a large part of that network is silently suffering without being aware, and the trade-offs are worth it. See Rust for example. People accept 5x mental load and 10x compile times for memory safety. Same for jj. People accept a much simpler interface because it makes their painful workflows "push button, magic happens" levels of simplicity. Or, the people who like jj work under time pressure and want to remove a time-sink from their workflows, again understandable and respectable.

Having something like "jj" is not a bad thing. What I'm squarely against is "git is dead, new king is jj. Now move to your new kingdom and worship jj" mentality.

[do_not_redeem]

I think you have it backwards. jj is absolutely for "a) Developers who want to understand their tools". The simpler data model opens up new workflows that weren't possible before.

Unifying concepts is not taking away any expressive power. It just makes the system as a whole simpler to reason about.

I think it's a similar step up in power as moving from Windows to Linux. On Windows, to toy with the system at all you need to set up a C++ project and dig through win32 API docs and deal with opening/closing handles and void* pointers just to change anything, so I rarely bothered. On Linux everything is right there in the file system so there's almost no friction to changing things. You can do anything imaginable in a minute or two with just a shell script.

In Linux, Everything Is A File. In Jujutsu, Everything Is A Commit.

[steveklabnik]

You’re making an understandable mistake. Jj being simpler doesn’t mean it is less powerful. It means it’s more powerful. This happens very rarely, but it is the case here. Removing the index and stash as unique concepts doesn’t mean that their use cases disappear: they gain power, because you can use any tool that works on a commit on your “index” or “stash” because they’re also just commits.

I actually like git’s CLI. I never understood why people wanted a simplified git. I’m never going back to git from jj. It’s just better.

[ziml77]

Being in group #1 does not mean that I want to interact with every system at the lowest possible levels. I want to interact in ways that fit how I work, not to fit how I work to the ways the system works.

> "git is dead, new king is jj. Now move to your new kingdom and worship jj"

No one is saying this. If you feel like people getting excited about Jujutsu is them telling you that you must love it, that's on you. The fact that it is built on top of Git means that even if others are using Jujutsu, you are not forced to when working in the same repos.

[stouset]

I was a git power user. I am comfortable with and understand the index, stash, rebases, the reflog, and all the rest. I have written a git implementation.

I have converted to jj and will never go back. It is simpler and more powerful.

[stouset]

> I personally never use rebase

Probably a lot of that is because it is painful. When it becomes a no-op, suddenly a lot of things become easy to do.

Do you ever want to go back and edit a previous unpublished commit? Yes fixups exist, but that’s a band aid over the fact that editing a previous one is annoying and hard.

Do you ever want to maintain a linear chain of branches? Branch A needs to be merged before Branch B needs to be merged before Branch C. It’s a massive pain with git, especially if you need to change Branch A. It’s a no-op in jj.

There are a ton of straightforward and useful workflows in git that are just completely impractical.

[bayindirh]

No, not because it's painful, I just don't need it.

> Do you ever want to go back and edit a previous unpublished commit?

Honestly, no? I plan what I'm going to change, do it, commit it, and if I messed up, I don't hide it, just fix it and write "I messed up X in $HASH. This fixes that".

> Do you ever want to maintain a linear chain of branches?

No, I always keep a single thing moving at one time. If the project is big, I use a branch per feature, if it's a smaller branch, there's a development branch. That's all. I have a habit of designing before touching code, so I always move in well planned moves.

It's not like that because I'm afraid of rebase. It's just how I design/implement software. Yes, it's generally not a group work, but I do what I do, and it works.

> There are a ton of straightforward and useful workflows in git that are just completely impractical.

That's fine. I don't claim otherwise. I just don't do to prefer source code / branch acrobatics. I'd love to share a seven year development tree to show how I work, but unfortunately that repo is not meant to be open, at least for now.

[Izkata]

> Do you ever want to go back and edit a previous unpublished commit? Yes fixups exist, but that’s a band aid over the fact that editing a previous one is annoying and hard.

Also unnecessary, "git rebase -i" has an "edit" command that pauses the rebase at that commit to let you do whatever.

[Valodim]

This is roughly the reaction I meant going into this discussion :)

The rebase next level part is not about using git rebase in the right way, it's about every command including status sometimes doing 15 rebases without even mentioning it.

[steveklabnik]

What jj does is not require you to pause. It’s fine with leaving stuff in a conflicted state, letting you do whatever you want as a next step. That may be resolving the rebase, but maybe you didn’t realize you were gonna have a conflict and want to get something else done real quickly.

In-memory, always succeeding rebases are just really nice.

[stouset]

And also you can just… edit a commit. It’s not some special side effect of a certain flag to a different command. You can just say “gosh I really wish I’d made some changes here” and either move changes in, or just jump in and live-edit it directly.

It’s really a completely different way of thinking, but shockingly, one that essentially directly maps to what your actual intentions are.