Nope, git is good enough, and is the global standard. We don't need more new VCS.
Great opinion. Have you tried it? It takes just 30 minutes to wash all the Stockholm syndrome off of you.
jj – the CLI for Jujutsu
131–140 of 517 posts
Re: jj – the CLI for Jujutsu
#132One of my favorite jj features is "jj absorb". For each change you've made in the current revision, it finds the last commit where you made a change near there, and moves your changes to that commit. Really handy when you forgot to make a change to some config file or .gitignore. You just "jj new", make the changes, and "jj absorb". No need to make a new commit or figure out where to rebase to. Oh, and not having to…
git absorb exists too fyi
Re: jj – the CLI for Jujutsu
#133> $ cargo install jj-cli@0.23.0 --locked
I won't install Rust just to test your software. Make a debian package like everyone else.
Re: jj – the CLI for Jujutsu
#134its almost impossible for me to tell if this better or worst than git i read few things about jj, and my conclusion 1. its different 2. very few user would really care about this difference i think git is good (not good enough, good just good, or really good) and unlike shells, i cant think of a reason to have mass migration to it people use zsh because apple choose it, and pwsh because microsoft settled on it, on li…
I may be reading too deeply but it sounds like you haven't even tried it. You should! Its really hard to live without it, once you feel it in your fingers.
Re: jj – the CLI for Jujutsu
#135> $ cargo install jj-cli@0.23.0 --locked I won't install Rust just to test your software. Make a debian package like everyone else.
I believe the full docs page does indicate that there are binaries to install via popular package managers [1]
Re: jj – the CLI for Jujutsu
#136Does JJ really prefer for me to think backwards? It wants me to start with the new and describe command, but with git I first make the changes and name the changeset at the end of the workflow. I also often end up with in a dirty repo state with multiple changes belonging to separate features or abstractions. I usually just pick the changes I want to group into a commit and clean up the state. Since it's git compatib…
think of jj like, I want to build xyz, ``` jj desc -m "feat: x y & z" ``` do the work. ``` jj split ``` Split up the parts and files that you want to be separate and name them. This will also allow you to rename stuff. ``` jj bookmark create worklabel-1 -r rev1 jj bookmark create worklabel-2 -r rev2 # Push both commits # since we just split them they are likely not inter-dependent # so you can rebase them both to bas…
I am dumb. why is that better than a git branch or a git worktree ?
Re: jj – the CLI for Jujutsu
#137jj sounds awesome. I think I’ll give it a shot.
But I found this article a bit long winded and ended up asking an LLM about it instead.
Re: jj – the CLI for Jujutsu
#138Can jj iterate through a list of repositories and clone them all to local storage? It isn't very hard to make a bash script to do it, but I have about six github repos, all of which frequently need to be put on a new machine. that kind of functionality would be cool to have out of the box.
Are you accessing these boxes via ssh or using them directly? If it's via ssh, I'd expect that you would already be using the clipboard for copying the names of them rather than typing them out manually, at which point copying `git clone && git clone && ...` would achieve the same thing.
Re: jj – the CLI for Jujutsu
#139jj is great and while it was an adjustment at first, I've never looked back. I feel like when you're working with other people, things never get reviewed and merged as quickly as you'd like. With jj, it's pretty low-cost to have a bunch of PRs open at once, and you can do something like `jj new ` to build stuff that requires all 3. This lets me do things like... not do a big refactoring in the same PR as adding a feature. I can have them both self-contained, but still start on the next step before they're all merged. It's easy to add changes on top, switching between the individual PRs as comments come up, etc.
I always liked doing things like this. At Google where we used a custom fork of Perforce, I told myself "NEVER DO STACKED CLs HAVE YOU NOT LEARNED YOUR LESSON YET?" If one CL depended on another... don't do it. With git... I told myself the same thing, as I sat in endless interactive rebases and merge conflict commits ("git rebase abort" might have been my most-used command). With jj, it's not a problem. There are merge conflicts. You can resolve them with the peace of mind as a separate commit to track your resolution. `jj new -d 'resolve merge conflict` -A @` to add a new commit after the conflicted one. Hack on your resolution until you're happy. jj squash --into @-. Merge conflict resolved.
It is truly a beautiful model. Really a big mental health saver. It just makes it so easy to work with other people.
Re: jj – the CLI for Jujutsu
#140Does JJ really prefer for me to think backwards? It wants me to start with the new and describe command, but with git I first make the changes and name the changeset at the end of the workflow. I also often end up with in a dirty repo state with multiple changes belonging to separate features or abstractions. I usually just pick the changes I want to group into a commit and clean up the state. Since it's git compatib…
> Does JJ really prefer for me to think backwards? It wants me to start with the new and describe command, but with git I first make the changes and name the changeset at the end of the workflow. Yes, but this is not backwards, the way you do it in git is backwards. =)
git promises "version control", this clearly implies that the versions predate the control: in this picture the git workflow is not backwards.