"Git is too hard" is never a good argument to promote the use of a different tool.
I use git on the terminal exclusively, never had an issue amending a commit or rebasing a branch, or even dealing with conflict resolution most of the time I just use one of the automatic strategies.
Switch to Jujutsu Already: A Tutorial
21–30 of 164 posts
Re: Switch to Jujutsu Already: A Tutorial
#22Right in the first paragraph.
> Needless to say, I just don’t get git.
What is there not to _get_, honestly? And why is jj so easier to get?
The author seems to focus on how great it is to make changes to your commit history locally, and that you shouldn't worry because it's not pushed yet.
The thing is, I don't want automatic. Automatic sucks. The point of version control is that I am able to curate my changes. The guards and rails of git is what makes me feel safe.
I am still failing to see why JJ is superior to git, or whatever.
Re: Switch to Jujutsu Already: A Tutorial
#23Weird cultish vibes I'm getting, especially the "i just dont get git" part. Shows that you did no research.
Re: Switch to Jujutsu Already: A Tutorial
#24I just don't have enough pain points with Git to move to something new. I don't have a problem remembering the ~5 commands I need most on any given workday. Between stashes, branches, temporary commits I later rebase, and recently worktrees, I don't lack for anything in my usage. It's universally used across both my public and corporate life, and neither does anyone need to learn a new tool to interact with my code b…
I don't hate git, I like it fine and, until recently, used it exclusively on all my projects (I still use it non-exclusively). Here's an article that's written from that viewpoint: https://www.stavros.io/posts/switch-to-jujutsu-already-a-tut... That having been said, I didn't hate Subversion either. It was fine.
> I don't hate git
Idk man, the first two paragraphs of the article very much make it sound like you hate git.
> Over the past few years, I’ve been seeing people rave about Jujutsu, and I always wanted to try it, but it never seemed worth the trouble, even though I hate git.
Re: Switch to Jujutsu Already: A Tutorial
#25Right in the first paragraph. > Needless to say, I just don’t get git. What is there not to _get_, honestly? And why is jj so easier to get? The author seems to focus on how great it is to make changes to your commit history locally, and that you shouldn't worry because it's not pushed yet. The thing is, I don't want automatic. Automatic sucks. The point of version control is that I am able to curate my changes. The…
If you don't want automatic, you shouldn't use git. It does too many things automatically, like update your branches' heads whenever you commit, for example.
Re: Switch to Jujutsu Already: A Tutorial
#26it's hard to take the article seriously when the author relies on a fuckgit alias on a regular basis
Re: Switch to Jujutsu Already: A Tutorial
#27I don't really understand the appeal of jj as someone who uses sublime merge [0].
It has good support for submodules, a lot of the editing commits (messages, squash, move etc...) is really easy and I can also see and edit my stashes directly. Is there any benefit to jj compared to this?
Re: Switch to Jujutsu Already: A Tutorial
#28Until jj supports `git rebase -x "cargo check --deny warnings"`, it's useless to me. jj has primitive support for fixing individual files that changed, but it cannot work on any linter or formatter that depends on other files.
Re: Switch to Jujutsu Already: A Tutorial
#29I have primarily used git in the terminal for more than a decade. I also used magit when I was primarily working in emacs (magit's great!). I now primarily use lazygit. While I'm not a fan of the whole UI, this is the only git tool that makes me go super fast while creating a near-perfect commit history. I tried using jj but immediately stopped after installation as it required a learning curve that I wasn't ready to commit to yet.
Re: Switch to Jujutsu Already: A Tutorial
#30I feel like anyone who spends just a couple of hours learning git will have a much better mental model than the crappy "Assembly line" model from the article.
Your real mental model of git should be an acyclic directed graph where the nodes are commits and the edges are ancestry. Commits represents snapshot of the project's state. Tags and branches are just text pointers to commits in the graph.
If you use this mental model, suddenly things like git rebase or git reset become far less mysterious and arcane since they are just simple graph operations. Like `git reset --hard X` means "Make current branch's text pointer point to X"