111–120 of 164 posts
Anyone using `jj`, how well does it scale? I routinely use .git folders that are 11GB (+4GB checked out files) and 10k+ branches without issue.
I 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…
If you've ever lived in a world of stacked commits with develop on main (i.e. not gitflow, no feature branches), combined with code review for every commit, git will soon start to aggravate you. Git doesn't make rebasing a chain or tree of commits pleasant. Git records merge resolutions and can reuse them, but it doesn't do the same thing for rebases, making them more repetitive and tedious than they should be. When…
There's a semi-recent addition that makes it a single command, the --update-refs flag to rebase (along with the --rebase-merges flag, formerly called --preserve-merges).
I 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 menta…
I understand git at a pretty deep level. I still very much prefer jujutsu. Its rebase is just so much more powerful than git. I regularly work on top of octopus merges in jj of all my in-review parallel PRs and when I want to rebase them all and the octopus merge and the various anonymous branches on top it takes 1 command. It’s so much more powerful than git it’s crazy.
I really loved jujutsu for the few weeks that I used it. However, I did find all my tools that rely on Git (eg Gitlab CLI that can open merge request from the current branch) breaking because JJ operations result in detached head in Git. In addition, mixing Git and JJ will result in your repos becoming really slow when you do need to run some Git operation.
Hm, I can't speak to the tools, I imagine you're right. I haven't found any slowness, though. Why would jj slow git down?
> Needless to say, I just don’t get git. I never got it, even though I’ve read a bunch of stuff on how it represents things internally. I’ve been using it for years knowing what a few commands do, and [...] > If you don't like Jujutsu, you're wrong It would be much more convincing if they had any idea of git that they were comparing it to.
Except, the fact that I have no idea of git after 20 years of use, whereas I have a great idea of jj after two months is exactly the point .
> One day I randomly decided to try again, but this time I asked Claude how to do
As this seems to be the reason for having "a great idea" , an alternative explanation
Earlier quoted context omitted.
If you've ever lived in a world of stacked commits with develop on main (i.e. not gitflow, no feature branches), combined with code review for every commit, git will soon start to aggravate you. Git doesn't make rebasing a chain or tree of commits pleasant. Git records merge resolutions and can reuse them, but it doesn't do the same thing for rebases, making them more repetitive and tedious than they should be. When…
> Git doesn't make rebasing a chain or tree of commits pleasant. There's a semi-recent addition that makes it a single command, the --update-refs flag to rebase (along with the --rebase-merges flag, formerly called --preserve-merges).
Would be nice, if it would also have a flag to choose that behaviour.
Earlier quoted context omitted.
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 worked with SVN and I hated it, merging branches and dealing with conflict resolution on SVN was like getting stepped on the balls
When I was an intern at GenericCorpo we had days we couldn't work because SVN was down. WTF was that?
Earlier quoted context omitted.
Except, the fact that I have no idea of git after 20 years of use, whereas I have a great idea of jj after two months is exactly the point .
Have you done this in those 20 years? > One day I randomly decided to try again, but this time I asked Claude how to do As this seems to be the reason for having "a great idea" , an alternative explanation
Earlier quoted context omitted.
Hm, I can't speak to the tools, I imagine you're right. I haven't found any slowness, though. Why would jj slow git down?
I noticed some of my hybrid repositories were slow on regular git commands (eg log) and running garbage collection manual resolved it. Perhaps, jj created a lot of unreachable objects?