91–97 of 97 posts
Earlier quoted context omitted.
I mean, undo alone is a killer JJ feature. Sure, you can always somehow undo any git operation if you dig deep enough, but the ease of use on the JJ side without question.
The oplog is absolutely amazing. Having such a comprehensive safety net means you can have absolutely zero fear from doing absolutely anything to your repo, because you can always return the repo itself back to a known-good state. It's git's reflog on steroids.
Earlier quoted context omitted.
I feel like submodules are one of Git's most misused features. They're intended as a method of pinning read-only upstream Git dependencies. And when used for that purpose, they're good at what they do. I think that people mostly get a bad taste in their mouths because they try to use submodules for building multi-repo workspaces where a developer might need to commit in some/all of the repos. They're a bad fit for th…
> They're intended as a method of pinning read-only upstream Git dependencies. Except, dependencies are rarely read-only.
Which, this is exactly how pinning dependencies works. However if you are mutating your dependencies frequently and want the reference to them to change at the same time, this is the big pain with submodules- gotta do both yourselves. Not to mention there are now logistical problems to answer as this cannot happen atomically in all scenarios, let alone automatically.
Earlier quoted context omitted.
Wouldn't you end up with like 1 million commits in a decent size projects really quickly?
It's not a commit per change - all changes made since the last commit are in a new commit. You then usually do one of two things: - Decide your changes are perfect, so add a commit message to this one and then create a new one on to to carry on - Decide you only want some of them so use `jj split -i` to select which ones you want and then it creates two commits - the stuff you want in a new named commit, and the stuf…
I am an extremely fervent believer in jj and use it exclusively since December '24, but I think it's useful to be accurate as possible for these kinds of trade offs. I don't use watchman snapshots specifically because of this downside.
Earlier quoted context omitted.
And do downstream PRs show just what changed or is the merge target against main which then just keeps accumulating differences? This is one of the strengths I appreciate about graphite which is that the PRs are always on the preceding branch but it knows that when you go to merge it should actually really retarget and merge against main.
(Graphite dev here) Yeah – the key thing here is that there is work to be done on the server, so JJ likely either needs its own forge or a GitHub App that handles managing PRs for each JJ commit. I'm a huge fan of the JJ paradigm – this is something I'd love for us to be able to do in the future once one or both of: - we have more bandwidth to go down this road - JJ is popular enough that its worthwhile for us to do…
Ironic, since if there are a bunch of people in my boat, the lack of us in jj's user base will make it that much harder for jj to cross the "popular enough to be worth supporting" threshold.
Earlier quoted context omitted.
(Graphite dev here) Yeah – the key thing here is that there is work to be done on the server, so JJ likely either needs its own forge or a GitHub App that handles managing PRs for each JJ commit. I'm a huge fan of the JJ paradigm – this is something I'd love for us to be able to do in the future once one or both of: - we have more bandwidth to go down this road - JJ is popular enough that its worthwhile for us to do…
As a satisfied customer of yours, the prospect of having to give up Graphite is the main thing keeping me from giving jj a try at my day job. Ironic, since if there are a bunch of people in my boat, the lack of us in jj's user base will make it that much harder for jj to cross the "popular enough to be worth supporting" threshold.
Jujutsu is so good. I'm using a megamerge workflow and absolutely loving it!