181–190 of 552 posts
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 copy-paste changes outside of the repository before committing.
Earlier quoted context omitted.
Thanks, can you link me to their perforce backend code? I don't see the string "perforce" or "p4" anywhere in the code and it's not coming up on search. > You can and should rewrite the un-pushed commits to clean up history prior to pushing changes upstream. My concern isn't just about pushing upstream. What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate that…
> What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate that it's ready. I was extremely hostile to this aspect of jj too, but I've settled on a workflow where @ (i.e. the change/commit referring to the working copy) is always the same, named ".WIP: …", and as such is clearly never supposed to break out of the local system, and can never accidentally get pushed…
You might be able to configure JJ to also block commits with certain descriptions as well, which might be useful in your case.
For a decade now I've been lamenting that git won the source control war. My complaints fall in two main categories: 1. The mental model is too complex: rebase or merge, detaching head, etc. A good UI can hide away some of this uglyness. It sounds like jj helps here. 2. Any source control in a terminal is just horrible, since you have no view of the state you're working with. I honestly never fully understood why dev…
There's other TUIs and GUIs, but jjui is by far the best.
Earlier quoted context omitted.
> with git rebase -i you can't decide to do something else in the middle of the rebase You absolutely can, to some degree. At any point in an interactive rebase you can just make your changes and do a normal `git commit` then do `git rebase --continue` along on your merry way. Unless you're talking about suspending the rebase and like switching branches, messing around, and then resuming the rebase, which is kind of…
I do mean suspending the rebase and going to do something else, yes. It's a weird thing to do in git , because the conditions that git creates makes it weird. It is completely natural with jj, because jj doesn't have any modal states at all. (This is one of the key reasons jj is both simpler and more powerful than git — no modal states.)
git checkout master
git rebase [whatever]
[rebasing stuff]
git tag rebasing
git checkout --detach master
[do random other stuff]
git tag todo
git checkout rebasing
[continue rebasing]
(To clarify, it has never occurred to me that I even want to do that, so I didn't knew how to do it. Yet I didn't even needed to consider a manual, it just follows naturally from the git user model even if it seams completely unidiomatic.)
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…
I’ve been trying unsuccessfully to convert my team to jujutsu. I feel like what would be great is a page that really shows some common but complicated operations in git and how much easier they are in jujutsu. Something like the elevator pitch here but expanded on without the depth of Steve’s tutorial. Maybe what I need to do is do a demo so people can see and ask questions.
https://v5.chriskrycho.com/essays/jj-init/ https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj... https://ofcr.se/jujutsu-merge-workflow
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.
Like… reflog?
Kinda! jj has two kinds of these logs: the evolog and the op log. The git reflog is based on, well, refs. Whenever a ref is updated, you get an entry. This log is per ref. That's HEAD, your branches, your tags, and your stash. jj's evolog is sorta similar, but also different: it's a log, but per change (think commit in git). This means it is broader than per ref, as it includes not just commits that correspond to a r…