371–380 of 552 posts
Earlier quoted context omitted.
Isn't graphite a pr review tool that still uses git?
It’s both. Their CLI has a lot of overlap with what you’d use jj for (rebasing, amending, etc), but does basically everything worse other than “creating stacked PRs”. Slower; refuses to work from a detached HEAD; gets confused more easily by changes on the remote.
For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out…
serious question as somebody who has never even looked into what jujutsu offers - unless you're a solo dev with some free time, what exactly is the selling point here?
edit: i didnt realise that its just a layer on top of git so that basically answers my question, fair
Earlier quoted context omitted.
Stacked diffs are a core part of my workflow, letting me “work ahead” without being blocked waiting for reviews. Setting them up in git is not to bad. Adding a change to the bottom of the stack, and restacking everything on top… that’s hell in git.
git rebase -i lets you reorder commits easily, as long as they don’t have conflicts. If they do, you’re in for a rough time. I struggle to see how a vcs could help with that, even if I’d be happy to be proven wrong. One cool tip to help with conflicts is the revert trick. If you have a conflict that you need resolved earlier in your commit chain, you can commit a cleanup that hides the conflict, revert it instantly a…
A vcs can allow you to commit conflicts and then commit their resolutions whenever necessary. This has been pioneered by darcs (IIRC) and jj also allows that.
The main things that drives me crazy about jj is that all changes are always staged implicitly. This is what SVN did back in the day, and git was a huge improvement by staging changes explicitly. I almost always have more changes in my repository that those which I want to include in the next commit. With git, I just add the changes I want. With jj (and svn), there’s not obvious way around it—you have to manually cop…
Earlier quoted context omitted.
Not a whole list of operations, but this comparison of one common operation between jj and git is what made it click for me. https://lottia.net/notes/0013-git-jujutsu-miniature.html
This article convinces me that what he wants to do is easier in jj, I just don't understand why he wants to do it. My quick summary is that in one case he's try to avoid "extra" commits and in another case he's trying to re-order some commits. In my usual work flow, both of those problems would be handled by the git-rebase-squash I do after the feature works.
Earlier quoted context omitted.
Git rebase is, frankly, a massive pain in the ass. It's worth doing if you care about it. I used a rebase-heavy workflow for a decade and a half. But having to drop everything you're in the middle of to fix an endless list of rebase conflicts sucks. And it sucks even worse when you screw up the conflict resolution halfway through and have to start over from scratch. Rebases also don't play nicely with stacked branche…
> having to drop everything you're in the middle of to fix an endless list of rebase conflicts sucks You can use git commit --fixup to record what you want to change in an earlier commit. > start over from scratch rerere > Branches based off your original changes don't get rewritten As written elsewhere: git rebase --update-refs. If you want to do it manually git rebase --onto.
jj just does it correctly by default.
> rerere
jj just does it correctly by default.
> As written elsewhere: git rebase --update-refs. If you want to do it manually git rebase --onto.
jj just does it correctly by default.
defaults matter.
JJ needs a GUI. I tried twice to switch for a project, both times came back to git. But then, I am still not fully grokking the "why bother", and suspect that if I had a UI it would be both less friction, and more understanding.
Earlier quoted context omitted.
> to reset or view the repo at a previous state What about `git reflog`?
That lets you see previously checked out revisions. Jujutsu keeps track of all previous repo state. In git, you can pull a new remote branch, delete that branch, and push the deletion. If you want to get that branch back, git reflog will only save you if you checked out that commit. If you didn't, you're SOL. Jujutsu will let you undo the delete operation, restore the repo to a state where the branch existed, or view…
Earlier quoted context omitted.
It's because what you see as the inferior approach involves less effort and friction for the developers. When you are told to separate general code improvements to another PR, or worse, to not do them, and create a Jira task for them so they can be adequately prioritized, it just saps your will to do so. You just won't do any improvements that fall outside the scope of the feature, because even just thinking about th…
> It's because what you see as the inferior approach involves less effort and friction for the developers. I can see that. From the other side of the PR though, it involves significantly _more_ work from a reviewer. The "red tape" of separating commits and opening separate PRs should be removed by the team. The effort of separating commits and opening separate PRs is minimal once you're comfortable with the tools. I…
The best way of getting changes is through is simply sitting down and talking with the reviewer. Most of these small PRS, splitting things, creating elaborate stacking systems are just technology hacks around a social/process problem. I've seen people make more of a mess trying to split pr's up where they are so fine grained its silly and actually had dependencies on commits they didn't realise they had which reviewers then had to resolve. Literally anything to avoid talking and working with people. People are trying to turn a tightly collaborative process and turn it into isolated single work units with no collaboration that just need a rubber stamp.
Earlier quoted context omitted.
By default, the top (current) commit acts like a staging area and in fact is implemented as a dirty working tree in git. Commits start live without a description, and can’t be pushed without adding one. jj commit names the current commit and creates a new empty, unnamed commit on top , which effectively is precisely git’s behaviour. I implore you to try it. In practice the distinction just doesn’t matter, except it’s…
Sure, sometimes I want to work with a WIP commit and then I'm just doing that in git. I think functionally of the stage is about the UI, so keeping it separate is kind of the point. I find that useful, as I can use both approaches, not sure how its better if jj can just use one? > to ask why they do this. This was what I was trying to explain. To me the feature is needing to manually mark every line to be committed.…