Still not finished unfortunately :( Guess Steve is currently busy writing the next big thing in programming languages ( https://steveklabnik.com/writing/thirteen-years-of-rust-and-... ) ?
jj – the CLI for Jujutsu
111–120 of 517 posts
Re: jj – the CLI for Jujutsu
#112If it ain't broke...
Re: jj – the CLI for Jujutsu
#113Earlier quoted context omitted.
Just don't ever use `edit`, use `new` instead; then your changes are tracked without making a mess. I think that's much nicer than juggling stashes in git.
> Just don't ever use `edit`, use `new` instead As a git-ist (?), if I'd ever move away from git, it would be to avoid tooling that has idioms like this (like git too has), if `jj` just gonna surface a bunch of new "bad ideas" (together with what seems like really good ideas), kind of makes it feel like it isn't worth picking up unless you don't already know git.
Re: jj – the CLI for Jujutsu
#114Does 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…
Re: jj – the CLI for Jujutsu
#115I'm giving jj a try but one aspect of it I dislike is edits to files are automatically committed, so you need to defensively create empty new commits for your changes. As in, want to browse the repo from a commit 2 weeks ago? Well if you just checkout that commit and then edit a file, you've automatically changed that commit in your repo and rebased everything after it on top of your new changes. So instead you creat…
This is literally jj's schtick and reason for existing, so I wouldn't be surprised if you decide it is not the tool for you.
Re: jj – the CLI for Jujutsu
#116Can 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.
for url in url1 url2 ..; do git clone $url; done
That’s not really a script but a basic one liner.Re: jj – the CLI for Jujutsu
#117Re: jj – the CLI for Jujutsu
#118Earlier quoted context omitted.
jj edit is the biggest jj footgun I can think of, as other comments said just use jj new. But also if you do accidentally edit or change something jj undo works surprisingly well. I found when using jj it worked best for me when I stopped thinking in commits (which jj treats as very cheap “snapshots” of your code) and instead focus on the “changes”. Felt weird for me at first, but I realized when I was rebasing with…
> jj edit is the biggest jj footgun I can think of Honestly, this is only because `git checkout` is so convoluted that we've collectively changed our expectations around the UX. "checkout" can mean switching to another branch (and creating it if you specify a flag but erroring if you don't), looking at a commit (in which case you have "detached HEAD" and can't actually make changes until you make a branch) or resetti…
Re: jj – the CLI for Jujutsu
#119Does 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…
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 base
# assuming rev1 is already on top of base
jj rebase -s rev2 -d base
jj git push
```
That is it.