[flagged]
jj – the CLI for Jujutsu
201–210 of 517 posts
Re: jj – the CLI for Jujutsu
#202jj 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 fea…
I'm having trouble understanding the value of this and most other supposed advantages of jj I'm seeing.
I'm trying to pinpoint if it's because 1) my workflow doesn't need jj's fancy stuff, 2) I've gotten so used to `git`'s "flaws" that I don't notice them, or 3) the git porcelain I use (magit) does a good enough job at managing the flaws.
If you need to build on something that requires changes from 3 open PRs, can't you just start a new branch from main, merge all 3 PRs into it, and get to work? As changes are applied to the open PRs, you can rebase. Obviously that might cause some merge conflicts here and there, but as long as the PRs aren't super overlapping, they should still be manageable. If there's a ton of overlap between 3 open PRs, that to me sounds like a problem in the workflow/plan, which must be dealt with regardless of the VCS or porcelain.
Re: jj – the CLI for Jujutsu
#203I really wanted to like JJ, it was handy for a few months when I used it. But for me in the end I reverted back to regular git. What triggered me to go back was I never got a really clean mental model for how to keep ontop of Github PRs, bring in changes from origin/main, and ended up really badly mangling a feature branch that multiple contributors were working on when we did want to pull it in. I'll probably try it…
This is good feedback, thanks. The next version of the tutorial will certainly focus on stuff like this, as I agree it's really important to teach people.
Re: jj – the CLI for Jujutsu
#204Earlier quoted context omitted.
That avoids the problem for the specific workflow of checking out an old revision (and it was what I was describing with checking out a new branch off the old commit and adding a blank commit to that branch), but another way this design bites me: At work I am constantly jumping around numerous repos because I might be working on repo but then someone on my team will ask for help with repo . So I'll turn on screen sha…
From your "polluted" snapshot, you can run `jj commit -i` and use the TUI to select only what you want.
Just like you can run `git add -p`
Re: jj – the CLI for Jujutsu
#205Earlier quoted context omitted.
> 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…
It's not "wildly" different behavior based on the thing it's pointing to. In all 3 cases, the command is pointed at a commit and the behavior is the same. Once you know that branches/HEAD are just named pointers to commits, then it becomes obvious you are always just working on commits and branches/ids/HEAD etc are just ways of referencing them.
> In all 3 cases, the command is pointed at a commit and the behavior is the same
echo "something" >> foo.txt
git checkout foo.txt
Re: jj – the CLI for Jujutsu
#206"It's more powerful and easier" is a great claim, but I need examples in this opening page to convince me of the pain I could save myself or the awesome things I'm living without.
Specific commands don't really showcase the appeal of jj. If anything they might scare someone at first glance. It's the fact that the workflows are intuitive and you never find yourself reaching for help to get something done. You really need to try it to understand it.
> that the workflows are intuitive
It can't be both intuitive and yet too complicated to show examples at the same time.
Re: jj – the CLI for Jujutsu
#207What happens when jj introduces this native repository format - break compatibility with all the popular git hosts? If jj is so great now and works with git as a backend, it’s tough to imagine why it’s worth pursuing a native and presumably incompatible backend.
Nothing will break. You just keep using the git backend if you want to keep being compatible with git.
> it’s tough to imagine why it’s worth pursuing a native and presumably incompatible backend.
Well, there's no active work on a "native" backend. There are basically three backends right now:
1. the git backend
2. A simple backend used for tests, you can think of it almost like a mock backend, you wouldn't use it for real work, but it's still useful as part of the test suite
3. the piper backend at google
There's not a lot of reason for anyone to produce another open source "native" backend, because 99% of open source projects use git.
Re: jj – the CLI for Jujutsu
#208"It's more powerful and easier" is a great claim, but I need examples in this opening page to convince me of the pain I could save myself or the awesome things I'm living without.
Specific commands don't really showcase the appeal of jj. If anything they might scare someone at first glance. It's the fact that the workflows are intuitive and you never find yourself reaching for help to get something done. You really need to try it to understand it.
The only intuitive interface is the nipple. All other things are learned.
I feel very comfortable using git. Maybe jj is better, but not seeing is not believing.
Re: jj – the CLI for Jujutsu
#209Still 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-... ) ?
To be honest, while Steve's tutorial was what got me interested in jj, other tutorials were better in actually helping me understand it.
This is why I'm glad we have many of them! Not everyone is going to resonate with my writing style.
Re: jj – the CLI for Jujutsu
#210Does jj have partial clones of remote repo?
jj does not have partial clones, but it does have sparse checkouts.