no problem! i will say tho that the normal method is still very handy. if you have a goal in mind you can just do jj new -m <message> and now you have a commit message to remind you what the goal is (and should it change you can always edit the message again)
what i find really powerful is if i’m doing some work on a change and i find i actually have to make another change beforehand i can just do jj new -B @ -m "Description of prerequisite change" and make that change and the work i was doing before is saved and automatically rebased! and so i end up with commits in logical order rather than strictly temporal order
How do others feel about the default format for jj log? To me, it seems cluttered and hard to parse at a glance, but I like that it tries to display a tree. More spacing would probably help me, but maybe you get used to it?
Still waiting to see if it clicks, as-is; definitely share your views on it, but I figure it’s not an accident and am curious to see how much more natural it gets. That said, I ended up having to override git log’s defaults a lot, too, so who knows.
Beautiful tutorial, and very concise, I like the short format so I can easily digest it and get my hands dirty on an existing local Git repo + start making jj aliases :-)
What is jj equivalent of git pull --rebase? I could not find that in any tutorial on jj, yet it’s something that I believe many use in cases where jj would fit well.
One other thing is that you cannot check out a revision directly […]
You’re looking for jj edit, @bahlo. Just be careful, since the semantics of this mean that your changes are all immediately added T-1000 style to the revision, which is usually not what at least I want. I know that the obslog means this is safe, but I usually do prefer just squashing constantly so I have a bit more control over what I’m doing. (Also protects me from my own ADHD brain if I start heading off in a different direction, since it’s a lot easier for me to squash only some revisions than to extract chunks of a diff out.)
In particular, if the earlier revision doesn’t have all the relevant gitignore entries, eg. build artifacts or resources, then using jj edit risks those getting added. Of course you can undo, but it can be annoying.
Most recently I changed the output directory of my static site generator, did a build, went back a bit with jj edit, and jj added all those build artifacts to the old revision. Oops.
jj currently does not support shallow/partial clones.
welp, that makes it pretty useless to me, as i work on a lot of large projects (eg. rust) and have limited disk space as well as a slow network connection.
changesets seem like they would be nice for when you’re waiting forever to get PRs merged, though.
Hey bahlo, this is confusing revision IDs with change IDs. See the glossary: https://martinvonz.github.io/jj/v0.22.0/glossary/
I made the exact same mistake. I think it’s something the jj docs could do a better job of introducing.
In short, a revision is a commit, but a change is how a commit evolves over time. One change can contain many revisions/commits.
Thanks! Updated the bit, but could still be more clear I think
worth noting the
jj commit [-m <message>]command exists, which iirc is about equivalent tojj describe [-m <message>] && jj newThat solves my other issue, updated the blog post. Thanks!
no problem! i will say tho that the normal method is still very handy. if you have a goal in mind you can just do
jj new -m <message>and now you have a commit message to remind you what the goal is (and should it change you can always edit the message again)what i find really powerful is if i’m doing some work on a change and i find i actually have to make another change beforehand i can just do
jj new -B @ -m "Description of prerequisite change"and make that change and the work i was doing before is saved and automatically rebased! and so i end up with commits in logical order rather than strictly temporal orderYeah I’ve done the latter, automatic rebase is really useful
How do others feel about the default format for
jj log? To me, it seems cluttered and hard to parse at a glance, but I like that it tries to display a tree. More spacing would probably help me, but maybe you get used to it?I basically have been using that format forever but with tutti-frutti colours.
https://pasteboard.co/ErkB66UitzN6.png
Still waiting to see if it clicks, as-is; definitely share your views on it, but I figure it’s not an accident and am curious to see how much more natural it gets. That said, I ended up having to override
git log’s defaults a lot, too, so who knows.There’s an alternative default that I find quite nice with more spacing. This is the config:
[Comment removed by author]
Beautiful tutorial, and very concise, I like the short format so I can easily digest it and get my hands dirty on an existing local Git repo + start making jj aliases :-)
Thanks!! That was the intention <3
What is
jjequivalent ofgit pull --rebase? I could not find that in any tutorial onjj, yet it’s something that I believe many use in cases wherejjwould fit well.jj git fetch && jj rebase -d xyz@origin.You’re looking for
jj edit, @bahlo. Just be careful, since the semantics of this mean that your changes are all immediately added T-1000 style to the revision, which is usually not what at least I want. I know that the obslog means this is safe, but I usually do prefer just squashing constantly so I have a bit more control over what I’m doing. (Also protects me from my own ADHD brain if I start heading off in a different direction, since it’s a lot easier for me to squash only some revisions than to extract chunks of a diff out.)In particular, if the earlier revision doesn’t have all the relevant gitignore entries, eg. build artifacts or resources, then using
jj editrisks those getting added. Of course you can undo, but it can be annoying.Most recently I changed the output directory of my static site generator, did a build, went back a bit with
jj edit, and jj added all those build artifacts to the old revision. Oops.OMG, thank you! Updated the post.
thought i’d check it out, and:
welp, that makes it pretty useless to me, as i work on a lot of large projects (eg. rust) and have limited disk space as well as a slow network connection.
changesets seem like they would be nice for when you’re waiting forever to get PRs merged, though.
Initial support for shallow clones will be in the next release (in 2 weeks). It was added in https://github.com/martinvonz/jj/pull/4448.