12 ms·

JJ Cheat Sheet

186 points by justinpombrio 2y ago

wsycharles0o 2y ago
I’m confused. Isn’t this exactly the same as git commands?
- steveklabnik 2y ago
  Many jj commands share names with git commands, yes. That doesn't always mean they do the same exact thing. There's lots that are different too.
  - ipaddr 2y ago
    Sounds like something ready for the mass population.
    - steveklabnik 2y ago
      It is true that if you're looking for a finished, polished product, jj is very much not that. It's pre-1.0. Lots of things will change. I still refuse to use anything else these days, but I can understand why someone else might not want to.
    - aidenn0 2y ago
      This was true of svn and git; both had command named the same as VCSs that were popular when they were introduced, but had semantics that were subtly (or not so subtly) different.
    - KingMob 2y ago
      Unironically, it is. The underlying storage engine is git, which is rock-solid. But to put it this way, I've been using jj for almost a year, and even without a 1.0 release, editor support, or mature tooling, it's still such an improvement over git, I've stopped using git 98% of the time.
  - lgas 2y ago
    > That doesn't always mean they do the same exact thing. There's lots that are different too. That's good. Gotta keep people on their toes.
    - steveklabnik 2y ago
      With `jj undo`, it's not a huge deal. I'm (mostly) kidding. jj has to weigh trying to be the best VCS it can be alongside factors like "how much will this confuse someone who's used to git." Both things are important, and balancing them is a tricky process. Take `jj commit` for example. This "does what git commit does," sorta. But also, not really? But if you're five minutes into `jj`, coming from `git`, then yeah, `jj commit` is exactly what you think it is. And that lets you be comfortable. Even though, from the `jj` perspective, it's a very bad name.
  - ashu1461 2y ago
    What is that one popular use case which git does really bad and jj does good ?
    - 3eb7988a1663 2y ago
      I am laughing. Fearless merging/rebasing/context switching? Having just one way of doing things? Best to ask the other way around at the current JJ flaws. Which right now would be tooling support and you actually have to be on top of your .gitignore.
    - steveklabnik 2y ago
      Virtually everything is easier. How much easier is up for debate. Part of the issue is that everything is interlocking. Small gains in multiple places end up feeling so, so much nicer, even if they may not seem like it. So for example, the index in git is a workflow pattern in jj, not a built in feature. This means that you don't have `git reset` with `--soft` vs `--hard` vs `--mixed`: You just have `jj edit`. This decision also means `jj rebase` can be entirely in memory, which means it's fast. But that wouldn't matter if conflicts weren't a first-class concept in jj, so things like rebase always succeed and immediately. Which doesn't sound like a big deal but you find yourself being able to rebase way more often and way more easily... It's not that git is bad. And it's not that it's bad at a specific thing. It's just that taking some of the other sides of some of the tradeoffs means that you get something that's smaller but also more powerful. And that's cool. I think the "mega merge" plus `jj absorb` might be one of the more flashy things: https://steveklabnik.github.io/jujutsu-tutorial/advanced/simultaneous-edits.html https://steveklabnik.github.io/jujutsu-tutorial/advanced/sim... but I don't even do that. The basics are still just nicer.
      - ashenke 2y ago
        So I've been hovering around jj for a while, trying to understand how it works, without suceeding in having a good mental model around it. I looked at this megamerge workflow and it's the first one that "clicked" for me (even though I'm not sure I understand the magic behind jj absorb, but I'll look into it). One thing though is that I don't quite understand how it would work in the context of a real git repo. Let's say I work on two branches, main and feature1, I'd create a [merge] commit that is has the two bookmarks as parents. But if after a fetch main has new changes, do I need to discard the current [merge] and recreate it again ? I can't find a way to just say "Update the parents so they track these bookmarks". I just tried it on a real repo, working on a change in a branch, then on a change on another branch, then adding a third branch I needed to work on that was not a parent yet, but this seems like a lot of boilerplate to always recreate my megamerge setup so I think I'm missing something
- arxanas 2y ago
  It's a bit unfortunate because most of the listed commands are indeed equivalent to Git commands. To give an example of new capabilities, in Git, you can't do the equivalent of jj rebase -r 'mine() & diff_contains("TODO")' -d 'heads(@::)' in any reasonable number of commands, which will 1) find all of the commits I authored with the string `TODO` in the diff 2) extract them from their locations in the commit graph 3) rebase all non-matching descendant commits onto their nearest unaffected ancestor commits 4) find the most recent work I'm doing on the current branch (topologically, the descendant commit of the current commit which has no descendants of its own, called a "head") 5) rebase all extracted commits onto that commit, while preserving the relative topological order and moving any branches. Furthermore, any merge conflicts produced during the process are stored for later resolution; I don't have to resolve them until I'm ready to do so. (That kind of VCS workflow is not useful for some people, but it's incredibly useful for me.)
  - porridgeraisin 2y ago
    So you're taking every single TODO commit and rebasing it on top of current? Why would we do that?
    - necauqua 2y ago
      ??.. wdym why, what?. Also this is just an example, there are a lot of very complex (from the point of git) things that are trivial like that in jj. Although if you're asking "why would we do that" then I don't even know what to tell you lol
      - nchmy 2y ago
        I think it was a very valid question. I was, and still am, wondering the same thing
        necauqua 2y ago
        I guess you could question the specific example, but to me the question sounded like "why would you do rebases". Like, for various reasons?. The point was that it's way easier and way safer to do rebases in jj, and it straight up allows to do complex stuff like the mentioned example easily and inderstandably, idk
nchmy 2y ago
Thanks for this! Just yesterday I decided to finally start really using jj with real work, whereas I had only fiddled around with it a few times while following tutorials over the past year. One suggestion - reverse the direction of the arrows: q->r rather than q<-r
- justinpombrio 2y ago
  Thanks for the kind word! Unfortunately the arrows are kind of confusing regardless of which way they go. You're suggesting they point forward in time, from the old commit to the new commit. The way they're drawn is the direction of the reference: a commit points at its parent. The argument in favor of each way the arrows could go feel about equally strong to me, and my understanding is that the convention in repo diagrams is for arrows to go in the direction of the reference, so that's what I went with.
- vermilingua 2y ago
  Something I've worried about trying to switch to jj: is there a chance that using it will cause noticable artifacts or issues in the upstream git repo? We're quite strict on tooling in my team and I don't want to get to a state where I can't digest the jj changes back into normal git commits for pushing. There's plenty about how you can use jj as a replacement but no clear guidance on what upstream commits will actually look like if you use it.
  - notmywalrus 2y ago
    The blockers for many are: - No support for LFS - No support for hooks (precommit, etc) - No? Bad? support for submodules - No? Bad? support for line ending styles If you don't care about those, you _should_ be able to use jj completely "undetected". It does encourage rewriting history more than some git workflows like. In terms of issues in the git repo -- there shouldn't be any. jj uses git as a backend, all commits are stored as git commits, etc. If you colocate the repo, you're able to use git commands directly.
    - vermilingua 2y ago
rtpg 2y ago
Workflow-wise I was struggling a bit to figure out how to work with the bookmarks in jj not moving along. I now have a bit of a new strategy: - When starting up a branch, right up the "final commit message", along with a bunch of notes on what I think I need and other TODOs - While working, when I want to checkpoint some work, I use jj split to chop up some chunk of work, describe it, and then edit up my TODOs this way the tip of my branch is always this WIP commit describing my end goal, I can find it, and I can add a bookmark to it. Instead of git "I add changes over time and make my commit graph move forward", it's "I have a final commit node and add commits _behind it_". Been working well enough.
- notmywalrus 2y ago
  You may be interested in the semi-standard `jj tug` alias [1], that moves "the most recent" bookmark up to `@-` [1]: https://github.com/jj-vcs/jj/discussions/5568 https://github.com/jj-vcs/jj/discussions/5568
  - oniony 2y ago
    This is great, thanks.
  - setheron 2y ago
    Amazing alias I've adopted. Should be standard.
  - abound 2y ago
    This is excellent, thank you! I've had my own `jj bm` (for "bookmark move") alias to do this, but that implementation is way better.
- christophilus 2y ago
  I’ve been using it for a bit. It is magical. I had some merge conflicts in a GitHub PR. I pulled everything down with jj, and the conflicts were gone. Pushed and presto. I do end up with descriptionless bookmarks that won’t push without a flag. So, I’m still doing something wrong. But it’s already saved me a few times this week during some gnarly refactoring and merges.
gjm11 2y ago
I think I'm confused by the box about "jj abandon", which (unlike all the other boxes) talks about "edits" rather than "files" -- which must be a deliberate choice because the legend at the bottom lists "edits" and "files" separately. Shouldn't "edits" be attached to the arrows rather than the nodes in the graphs? So not r [edit3] --> q [edit2] --> p [edit1] but r --[edit3]--> q --[edit2]--> p --[edit1]--> o, where o is p's predecessor. (I think you could do without "edit1" here.) And then "jj abandon q", if I'm understanding it right, turns r --[edit3]--> q --[edit2]--> p into r --[edit3]--> p. (I am not certain I've understood the official docs for "jj abandon" correctly, so it's very possible that I'm wrong about what it does, in which case obviously the above is wrong. But whatever it does, if you're distinguishing "files" from "edits", surely the "edits" go on the edges rather than the nodes of the revision-graph.)
- steveklabnik 2y ago
  It's trying to point out the common argument that's passed to each command: `jj restore` with no arguments is virtually the same as `jj abandon`, but in practice that means that `jj restore` tends to be called with a file as an argument, and `jj abandon` gets called with a revision (which he's calling edit here). It is in fact a node. The arrows are still just relationships between nodes. > if I'm understanding it right, turns r --[edit3]--> q --[edit2]--> p into r --[edit3]--> p. You are right with the outcome but wrong about why. `jj abandon -r q` would turn `r --> q --> p` into `r --> p`, but you're passing the node as the argument (r is for revision) not the edge. Hilariously, I am literally working on writing version 2 of my tutorial right now, and I'm literally talking about `jj abandon`. What do you think about this? It cuts off where I literally am right now: https://gist.github.com/steveklabnik/71165f9ff5e13b1e95902c45ae8f5320 https://gist.github.com/steveklabnik/71165f9ff5e13b1e95902c4...
  - notmywalrus 2y ago
    > > if I'm understanding it right, turns r --[edit3]--> q --[edit2]--> p into r --[edit3]--> p. > You are right with the outcome but wrong about why. `jj abandon -r q` would turn `r --> q --> p` into `r --> p` Well, it can do two things. Given: `r(f3) --[e3]--> q(f2) --[e2]--> p(f1)` `jj abandon -r q` makes `r(f1+e3) --[e3]--> p(f1)`, as if you had rebased `r` onto `p`. `jj abandon -r q --restore-descendants` makes `r(f3) --[e2+e3]--> p(f1)`, as if you had squashed `r` into `q`.
sundarurfriend 2y ago
The biggest blocker for me to switch to using jj currently is https://github.com/jj-vcs/jj/issues/3949 https://github.com/jj-vcs/jj/issues/3949 which is that it doesn't have a `core.fileMode` option equivalent. What this means in practice is that it's unusable from WSL when your repo is on an NTFS filesystem. It gets confused by NTFS's lack of executable permission bit and makes spurious changes/commits. It's a small thing, but while jj adds some convenience, it doesn't add enough (for me) to offset the inconvenience of changing my workflow to not use WSL. (Another relatively minor inconvenience is its inability to use your SSH configs. So if you have multiple key pairs and need to use specific ones that aren't jj's default pick, an ssh-agent is the only way.) That said, I would 100% recommend jj over git for any new programmer who hasn't yet had to contort their brain already into the git ways. All the things that git's UI does a great job of obscuring and presenting in a confusing way, jj presents in a straightforward way that makes sense and is easy to remember.
- steveklabnik 2y ago
  Ah, I use `jj` on WSL every day, so I was confused at first, but that's because I don't share the drive there any more. That absolutely makes sense as a blocker. The autocrlf bit is a bit of a bummer on Windows, too. > Another relatively minor inconvenience is its inability to use your SSH configs. This should be much better as of last week's release, when you can say "please use git as a subprocess rather than libgit2/gix".
  - stouset 2y ago
    > This should be much better as of last week's release, when you can say "please use git as a subprocess rather than libgit2/gix". I understand the decision here from an SSH-support situation, but doesn't this feel like a bit of a step backwards?
    - steveklabnik 2y ago
      It’s just a tough spot to be in: libgit2 has always worked a bit differently than the binaries, gix is incomplete. Ideally gix will be good enough that it could just be used, but things aren’t there yet.
infogulch 2y ago
Is there a short description of how jj works specifically from the perspective of a seasoned git user? I more or less understand git -- how to use it as well as its building blocks -- so the caveats and generalizations and glossing-over that are appropriate for a more general audience seem to get in the way of my understanding what's going on underneath.
- justinpombrio 2y ago
  This might be what you're looking for: https://jj-vcs.github.io/jj/latest/git-comparison/ https://jj-vcs.github.io/jj/latest/git-comparison/
- steveklabnik 2y ago
  jj is truly its own VCS, so to deeply understand it, it's more than short. But it does map to git, and so you can sorta explain it in git terms. It's really kind of like "what if you tried to build hg on top of git?" jj is kind of hard to really explain because a bunch of the design decisions have subtle but important impacts on other decisions, so your first impression of a feature may be slightly wrong because you don't get the implications yet. jj is sort of the same as git: you have a DAG of snapshots of your project. The differences are in how you interact with those things. To try and put it in git terms: 1. Commits are mutable, not immutable (but we'll talk about is more later) 2. You're always working in the context of some commit 3. When you modify a file, it becomes part of that commit (we'll talk about the index in a minute) 4. You don't need to care about branches at all, the "detached head" state is the nrom. 5. commits are immutable in the "immutable data structures" sense, in that whenever you modify them, it's almost like you're adding a commit to them. this is why jj calls its "commits" "changes", change IDs stay stable as you edit them, and they produce new git commits for every edit. 6. Because of how this all fits together, you don't need an explicit index; if you want one, you can just `jj new` twice to get two changes on top of each other, and then edit your files. When you have what you want, `jj squash` will move the diff into the parent commit, and now it's "part of that feature" or whatever. If you want `git add -p`, that's `jj squash -i`. That is kind of it on some level, but in reality, it's kind of hard to convey how a few, smaller, more orthogonal primitives let you do everything you can do in git, but easier. (I tried to actively think of cases last night and only came up with two or three that were easier in git than jj, and jj will have fixes for most of those soonish.) stashing is another great example of a feature of git that's just a workflow pattern in jj. There's just... it's a lot. It's hard to know what the best thing really is. Other than `jj undo` :) (I've got this on the brain since I am literally working on my tutorial right now)
wyldfire 2y ago
Does jujutsu have anything like "git am"? I'd like to take a series of patches and jj-ify them so I can play with it. I get that maybe I can't expect to cherry pick a commit because it's naturally different from git. but if I have a patch it seems like I should be able to apply those as jj changes?
- KingMob 2y ago
  There's no succinct command designed to work with mailed patches yet, but you could mimic it with a little scripting. Maybe something like this? ``` for patch_file in "$@"; do jj new patch -p1 < "$patch_file" author=$(extract_author "$patch_file") commit_message=$(extract_commit_message "$patch_file") jj describe -m "$commit_message" --author "$author" done ```
jjfanboy 2y ago
I love jj and you could pry it from my cold dead hands but I can't make sense of nearly any of these pictograms. :(
bedros 2y ago
Anyone knows of vs code editor extension that works with .jj dir
- ilyagr 2y ago
  https://www.visualjj.com/ https://www.visualjj.com/ Better link: https://marketplace.visualstudio.com/items?itemName=visualjj.visualjj https://marketplace.visualstudio.com/items?itemName=visualjj...
conradludgate 2y ago
I still don't understand the way jj handles conflicts. If I rebase and then fix a conflict later, are those conflict markers going to appear in some of the commits on github when I push? Maybe I'm in the minority, but I like fixing conflicts as I go. What am I missing?
- martinvonz 2y ago
  > I still don't understand the way jj handles conflicts. See https://jj-vcs.github.io/jj/latest/conflicts/ https://jj-vcs.github.io/jj/latest/conflicts/. > If I rebase and then fix a conflict later, are those conflict markers going to appear in some of the commits on github when I push? We error out if you try to push conflicts because the Git remote would probably not know how to interpret them. We will probably add an option to allow it later because it can be useful to be able to share conflicts with others if you know that they're also using jj. > Maybe I'm in the minority, but I like fixing conflicts as I go. What am I missing? You can still do that. Hopefully the above answers your question.
  - glandium 2y ago
    > See https://jj-vcs.github.io/jj/latest/conflicts/ https://jj-vcs.github.io/jj/latest/conflicts/. Honestly, this page doesn't really make a compelling case as to how checking out the commit with a conflict and amending is better than git rebase/whatever --continue. Overall, it's also quite abstract. Concrete examples would be deeply appreciated.
    - necauqua 2y ago
      It's very obviously miles better because there's no global rebase state?. So you can just leave the conflict there an go work on something else then come back. Also it's not sequential like --continue you've mentioned. Also you can rebase the conflicting commits themselves, and by doing so potentially resolve the conflict and the resolution will propagate. For example manually undoing the rebase while useless (there's jj undo after all) shows that.
khana 2y ago
[dead]
tripple6 2y ago
I've seen several posts on jj, but could anyone please tell what can't be done by git, or what is harder in git but super-easy in jj by providing the sequence of git commands and jj commands for comparison?
- martinvonz 2y ago
  To move the changes in file `foo` in the working copy into a past commit `X`: `git commit --fixup=X foo; git stash; git rebase -i X^; git stash pop` `jj squash --into X foo`
  - Martinussen 2y ago
    That looks more like a git alias than a job for an entirely new tool, to me. How many of the core functions do you really need to cover before `jj` itself becomes redundant?
    - martinvonz 2y ago
      I think you misunderstood. Did you see the list of features? My example is not the only thing jj does.
    - martinvonz 2y ago
      I apologize if my sibling comment sounded harsh. I think you were saying that jj could be implemented as some Git aliases. Given the information available in this thread, that might seem reasonable. I didn't realize that this thread did not include a link to the project's docs. Sorry about that.
  - Aissen 2y ago
    You can simplify this: git commit --fixup X ; git rebase --interactive --autostash --autosquash X^ If you do that often, an alias might help; I have one for the second command above. You might want to look at git-fixup or git-absorb for automatically finding the "X" commit. Aside: I really ought to try jj, it looks very promising.
weinzierl 2y ago
I tried to get into Jujutsu several times and tried to love it, but somehow it seems there is little overlap between the issues I have with git (which there are plenty) and the problems jj tries to solve. My impression is that the main motivation behind jj is that Google realized how difficult and costly it is to train all new hires in their internal tooling but did not want to open-source it completely. So they came up with a thin UI layer, made it workable with git as a backend and published it in the hope it will catch on.
- bjackman 2y ago
  I have no opinion on whether JJ is good but I am pretty confident your impression about the reason for its shortcomings is wrong. Google has a basically tolerable and pretty easy-to-learn Mercurial-based frontend for its bizarre legacy Perforce system. Everything about JJ screams to me that it's been created as the passion project of someone who really wants to build a better VCS, making it compatible with Git was necessary to give it a chance of adoption, and making it compatible with Piper (Google's Perforce thing) was a way to get it funded as a potential benefit to Google. Top-down Google engineering would never produce a project like this IMO.
  - oniony 2y ago
    I thought Google moved off of their struggling Perforce server onto their homegrown Piper VCS.
    - bjackman 2y ago
      Piper is an extended reimplementation of Perforce (Piper is piper, expanded recursively. It's so meta, even this acronym)
      - steveklabnik 2y ago
        And while it's not public, jj has a piper backend, so that folks at Google can use jj (This is also why I have some confidence that jj truly is backend agnostic, it has two real backends already.)
globular-toast 2y ago
So jj calls commits "changes", and this is less confusing? Interesting. I find when you dig into people's understanding of git (or version control in general), a lot of them understand it as storing a sequence of diffs. This small thing breaks their understanding of the whole system. Calling them "changes" seems like it would reinforce this belief. Or is that the idea? Does jj embrace this perhaps more intuitive "sequence of diffs" view, but more successfully hide the "sequence of commits" reality?
- steveklabnik 2y ago
  > So jj calls commits "changes", and this is less confusing? Sort of. It has both changes and commits, actually. (and sometimes commits are called revisions.) jj log @ muzrswxs steve@steveklabnik.com 2025-02-12 10:23:11 85b41b31 │ (empty) (no description set) ○ wotxrwpp steve@steveklabnik.com 2025-02-12 10:23:09 24ce0a16 │ (empty) (no description set) ○ ztxxskuu steve@steveklabnik.com 2025-02-11 18:20:56 1b3e12ac │ run sqlx migrate as part of deploy process ◆ qwovsnvt steve@steveklabnik.com 2025-02-11 17:45:24 trunk b224ca8b │ <redacted> Okay, so muzrswxs is a change ID. It's true that we're connecting changes in a graph, and that that forms history. So in that sense, it's like a git commit. But because changes are mutable (well, the ○ ones and @ are, the ◆ there is not), they are implemented as a sequence of commits. So if you look on the far right there, you'll see 85b41b31 and then below it, 24ce0a16. Below that, 1b3e12ac. These are commit IDs. The first two changes are empty, so what happens if we modify a file? jj log @ muzrswxs steve@steveklabnik.com 2025-02-12 10:28:18 404a73b1 │ (no description set) ○ wotxrwpp steve@steveklabnik.com 2025-02-12 10:23:09 24ce0a16 │ (empty) (no description set) ○ ztxxskuu steve@steveklabnik.com 2025-02-11 18:20:56 1b3e12ac │ run sqlx migrate as part of deploy process ◆ qwovsnvt steve@steveklabnik.com 2025-02-11 17:45:24 trunk b224ca8b │ <redacted> Note that (empty) went away on that head change there, and its change ID is still muzrswxs. But the commit ID has changed from 85b41b31 to 404a73b1. None of the parents changed, of course. We can even take a look at this history: jj evolog --summary @ muzrswxs steve@steveklabnik.com 2025-02-12 10:28:18 404a73b1 │ (no description set) │ M README.md ○ muzrswxs hidden steve@steveklabnik.com 2025-02-12 10:23:11 85b41b31 (empty) (no description set) The evolution log will show us how our change has evolved over time: first we had 85b41b31, then we modified README.d and now we're at 404a73b1. > I find when you dig into people's understanding of git (or version control in general), a lot of them understand it as storing a sequence of diffs. This small thing breaks their understanding of the whole system. I agree with you in some sense, but also, kinda don't. That is, I agree that thinking git stores diffs is not correct, but I'm not fully sold on how big of a deal it is to be incorrect here. And once you really get into things, like, how packfiles are implemented, diffs are present. > Calling them "changes" seems like it would reinforce this belief. Or is that the idea? Does jj embrace this perhaps more intuitive "sequence of diffs" view, but more successfully hide the "sequence of commits" reality? I can assure you that these names are a heated kind of debate internally. I actually said two days ago "hey, so we have changes, commits, and then revision as a synonym for commit. shouldn't commit be a synonym for revision? because 'revision' is kind of an abstract idea, but 'commit' is git-specific, so like, I think it should be "we have changes, and changes have revisions, but the git backend implements revisions as commits" and that thread is still going this morning, with links to many previous discussions. Someone even wrote a blog post a year ago https://blog.waleedkhan.name/patch-terminology/ https://blog.waleedkhan.name/patch-terminology/ jj is still figuring out how best to present its ideas. I really like "change and revision" to describe these two things, but a lot of folks are concerned that "change" is too generic and is hard to figure out, that is, when I said this above > its change ID is still muzrswxs. But the commit ID has changed This is two different uses of the word "change". Is that confusing? Maybe. Is it confusing enough to find another word? Not sure.
geenat 2y ago
Auto-commit of large files and no way to un-bloat your repo is a showstopper for me no matter how good the DX might be. Large file handling needs to be sane in any new VCS, IMHO, as this is a main failing of git (..without the extra legwork of git-lfs). Edit: https://github.com/jj-vcs/jj/issues/80 https://github.com/jj-vcs/jj/issues/80 Could maybe bring jj up to parity with git here
- aseipp 2y ago
  Large file handling has improved in recent versions, FWIW; large files are left untracked if they violate the size limit (no auto track), you have to selectively add them at that point. Note that you can unbloat your local copy by pruning the operation log and then running jj gc if you accidentally add blobs and stuff; though if you push the blobs somewhere you obviously can't undo that so easily, that's no different than Git. Git's underlying storage format just isn't a very good fit for any kind of "large-ish file" storage; Git LFS is mostly just hack and it is unlikely to be supported anytime soon. Our hands are a bit tied on that front. My impression is that most of the interest and momentum for solving the "large files problem" would preferably be invested in a native non-Git backend for Jujutsu.
deleted 2y ago
[deleted]
mystickphoenix 2y ago
Something that I've been struggling to wrap my brain around is: 1. Can I use jj inside a repo that was already initialized with git? I think the answer is yes, but I haven't found a tl;dr for it. 2. What does the workflow look like to use jj on an existing git repo that all of your coworkers use git for?
- steveklabnik 2y ago
  > Can I use jj inside a repo that was already initialized with git? Yes. > What does the workflow look like to use jj on an existing git repo that all of your coworkers use git for? I struggle a little to answer this because on some level, the answer is "whatever you'd like it to be." That is, from your co-workers' perspective, nothing changes. You push some changes up to a git repo, they have no clue you used jj to do it. But I also feel like that maybe isn't answering your question.
  - mystickphoenix 2y ago
    I suppose what I'm looking for is maybe a translation from git to jj from the perspective of working in a repo with other users that are using git. Something along the lines of: 1. init jj in an existing git repo 2. instead of branching, do x, y, z 3. instead of committing after changes are done, do x, y, z 4. when pushing, do x, y, z 5. if someone else pushes to the same branch, here's how to handle it 6. if someone rebases and force pushes the branch, here's how to handle it 7. if you have merge conflicts, here's how to handle that I think I'm having a hard time trying to grok the jj "mental model" while simultaneously understanding how it translates to an existing git repo. I suspect for jj to get traction outside of single devs or companies that use jj exclusively, some extra focus in the docs giving guidance in the liminal space between would be super helpful.
    - steveklabnik 2y ago
      Ahh, I see, thanks. > some extra focus in the docs giving guidance in the liminal space between would be super helpful. I'm working on this! https://steveklabnik.github.io/jujutsu-tutorial/real-world-workflows/intro.html https://steveklabnik.github.io/jujutsu-tutorial/real-world-w... describes the most basic two workflows for 2-3. https://steveklabnik.github.io/jujutsu-tutorial/sharing-code/intro.html https://steveklabnik.github.io/jujutsu-tutorial/sharing-code... tries to explain 4-6 (but isn't as complete as it should be), and there's an unwritten place for 7 to exist in the future. I don't think these things are perfect yet, and I'm actually re-writing the whole thing, and it's going to focus on exactly these things, and there's interest in upstreaming the whole thing. That is partially why I asked, because I'm trying to make it so that these things are more easy for you in the future :) So I do really appreciate the answer.
159jonie158 2y ago
ROBLOX BLOX FRUIT
159jonie158 2y ago
[flagged]

JJ Cheat Sheet

186 points by justinpombrio 2y ago

wsycharles0o 2y ago

I’m confused. Isn’t this exactly the same as git commands?

steveklabnik 2y ago
Many jj commands share names with git commands, yes. That doesn't always mean they do the same exact thing. There's lots that are different too.
- ipaddr 2y ago
  Sounds like something ready for the mass population.
  - steveklabnik 2y ago
    It is true that if you're looking for a finished, polished product, jj is very much not that. It's pre-1.0. Lots of things will change. I still refuse to use anything else these days, but I can understand why someone else might not want to.
  - aidenn0 2y ago
    This was true of svn and git; both had command named the same as VCSs that were popular when they were introduced, but had semantics that were subtly (or not so subtly) different.
  - KingMob 2y ago
    Unironically, it is. The underlying storage engine is git, which is rock-solid. But to put it this way, I've been using jj for almost a year, and even without a 1.0 release, editor support, or mature tooling, it's still such an improvement over git, I've stopped using git 98% of the time.
- lgas 2y ago
  > That doesn't always mean they do the same exact thing. There's lots that are different too. That's good. Gotta keep people on their toes.
  - steveklabnik 2y ago
    With `jj undo`, it's not a huge deal. I'm (mostly) kidding. jj has to weigh trying to be the best VCS it can be alongside factors like "how much will this confuse someone who's used to git." Both things are important, and balancing them is a tricky process. Take `jj commit` for example. This "does what git commit does," sorta. But also, not really? But if you're five minutes into `jj`, coming from `git`, then yeah, `jj commit` is exactly what you think it is. And that lets you be comfortable. Even though, from the `jj` perspective, it's a very bad name.
- ashu1461 2y ago
  What is that one popular use case which git does really bad and jj does good ?
  - 3eb7988a1663 2y ago
    I am laughing. Fearless merging/rebasing/context switching? Having just one way of doing things? Best to ask the other way around at the current JJ flaws. Which right now would be tooling support and you actually have to be on top of your .gitignore.
  - steveklabnik 2y ago
    Virtually everything is easier. How much easier is up for debate. Part of the issue is that everything is interlocking. Small gains in multiple places end up feeling so, so much nicer, even if they may not seem like it. So for example, the index in git is a workflow pattern in jj, not a built in feature. This means that you don't have `git reset` with `--soft` vs `--hard` vs `--mixed`: You just have `jj edit`. This decision also means `jj rebase` can be entirely in memory, which means it's fast. But that wouldn't matter if conflicts weren't a first-class concept in jj, so things like rebase always succeed and immediately. Which doesn't sound like a big deal but you find yourself being able to rebase way more often and way more easily... It's not that git is bad. And it's not that it's bad at a specific thing. It's just that taking some of the other sides of some of the tradeoffs means that you get something that's smaller but also more powerful. And that's cool. I think the "mega merge" plus `jj absorb` might be one of the more flashy things: https://steveklabnik.github.io/jujutsu-tutorial/advanced/simultaneous-edits.html https://steveklabnik.github.io/jujutsu-tutorial/advanced/sim... but I don't even do that. The basics are still just nicer.
    - ashenke 2y ago
      So I've been hovering around jj for a while, trying to understand how it works, without suceeding in having a good mental model around it. I looked at this megamerge workflow and it's the first one that "clicked" for me (even though I'm not sure I understand the magic behind jj absorb, but I'll look into it). One thing though is that I don't quite understand how it would work in the context of a real git repo. Let's say I work on two branches, main and feature1, I'd create a [merge] commit that is has the two bookmarks as parents. But if after a fetch main has new changes, do I need to discard the current [merge] and recreate it again ? I can't find a way to just say "Update the parents so they track these bookmarks". I just tried it on a real repo, working on a change in a branch, then on a change on another branch, then adding a third branch I needed to work on that was not a parent yet, but this seems like a lot of boilerplate to always recreate my megamerge setup so I think I'm missing something
arxanas 2y ago
It's a bit unfortunate because most of the listed commands are indeed equivalent to Git commands. To give an example of new capabilities, in Git, you can't do the equivalent of jj rebase -r 'mine() & diff_contains("TODO")' -d 'heads(@::)' in any reasonable number of commands, which will 1) find all of the commits I authored with the string `TODO` in the diff 2) extract them from their locations in the commit graph 3) rebase all non-matching descendant commits onto their nearest unaffected ancestor commits 4) find the most recent work I'm doing on the current branch (topologically, the descendant commit of the current commit which has no descendants of its own, called a "head") 5) rebase all extracted commits onto that commit, while preserving the relative topological order and moving any branches. Furthermore, any merge conflicts produced during the process are stored for later resolution; I don't have to resolve them until I'm ready to do so. (That kind of VCS workflow is not useful for some people, but it's incredibly useful for me.)
- porridgeraisin 2y ago
  So you're taking every single TODO commit and rebasing it on top of current? Why would we do that?
  - necauqua 2y ago
    ??.. wdym why, what?. Also this is just an example, there are a lot of very complex (from the point of git) things that are trivial like that in jj. Although if you're asking "why would we do that" then I don't even know what to tell you lol
    - nchmy 2y ago
      I think it was a very valid question. I was, and still am, wondering the same thing
      - necauqua 2y ago
        I guess you could question the specific example, but to me the question sounded like "why would you do rebases". Like, for various reasons?. The point was that it's way easier and way safer to do rebases in jj, and it straight up allows to do complex stuff like the mentioned example easily and inderstandably, idk

nchmy 2y ago

Thanks for this! Just yesterday I decided to finally start really using jj with real work, whereas I had only fiddled around with it a few times while following tutorials over the past year. One suggestion - reverse the direction of the arrows: q->r rather than q<-r

justinpombrio 2y ago
Thanks for the kind word! Unfortunately the arrows are kind of confusing regardless of which way they go. You're suggesting they point forward in time, from the old commit to the new commit. The way they're drawn is the direction of the reference: a commit points at its parent. The argument in favor of each way the arrows could go feel about equally strong to me, and my understanding is that the convention in repo diagrams is for arrows to go in the direction of the reference, so that's what I went with.
vermilingua 2y ago
Something I've worried about trying to switch to jj: is there a chance that using it will cause noticable artifacts or issues in the upstream git repo? We're quite strict on tooling in my team and I don't want to get to a state where I can't digest the jj changes back into normal git commits for pushing. There's plenty about how you can use jj as a replacement but no clear guidance on what upstream commits will actually look like if you use it.
- notmywalrus 2y ago
  The blockers for many are: - No support for LFS - No support for hooks (precommit, etc) - No? Bad? support for submodules - No? Bad? support for line ending styles If you don't care about those, you _should_ be able to use jj completely "undetected". It does encourage rewriting history more than some git workflows like. In terms of issues in the git repo -- there shouldn't be any. jj uses git as a backend, all commits are stored as git commits, etc. If you colocate the repo, you're able to use git commands directly.
  - vermilingua 2y ago

rtpg 2y ago

Workflow-wise I was struggling a bit to figure out how to work with the bookmarks in jj not moving along. I now have a bit of a new strategy: - When starting up a branch, right up the "final commit message", along with a bunch of notes on what I think I need and other TODOs - While working, when I want to checkpoint some work, I use jj split to chop up some chunk of work, describe it, and then edit up my TODOs this way the tip of my branch is always this WIP commit describing my end goal, I can find it, and I can add a bookmark to it. Instead of git "I add changes over time and make my commit graph move forward", it's "I have a final commit node and add commits _behind it_". Been working well enough.

notmywalrus 2y ago
You may be interested in the semi-standard `jj tug` alias [1], that moves "the most recent" bookmark up to `@-` [1]: https://github.com/jj-vcs/jj/discussions/5568 https://github.com/jj-vcs/jj/discussions/5568
- oniony 2y ago
  This is great, thanks.
- setheron 2y ago
  Amazing alias I've adopted. Should be standard.
- abound 2y ago
  This is excellent, thank you! I've had my own `jj bm` (for "bookmark move") alias to do this, but that implementation is way better.
christophilus 2y ago
I’ve been using it for a bit. It is magical. I had some merge conflicts in a GitHub PR. I pulled everything down with jj, and the conflicts were gone. Pushed and presto. I do end up with descriptionless bookmarks that won’t push without a flag. So, I’m still doing something wrong. But it’s already saved me a few times this week during some gnarly refactoring and merges.

gjm11 2y ago

I think I'm confused by the box about "jj abandon", which (unlike all the other boxes) talks about "edits" rather than "files" -- which must be a deliberate choice because the legend at the bottom lists "edits" and "files" separately. Shouldn't "edits" be attached to the arrows rather than the nodes in the graphs? So not r [edit3] --> q [edit2] --> p [edit1] but r --[edit3]--> q --[edit2]--> p --[edit1]--> o, where o is p's predecessor. (I think you could do without "edit1" here.) And then "jj abandon q", if I'm understanding it right, turns r --[edit3]--> q --[edit2]--> p into r --[edit3]--> p. (I am not certain I've understood the official docs for "jj abandon" correctly, so it's very possible that I'm wrong about what it does, in which case obviously the above is wrong. But whatever it does, if you're distinguishing "files" from "edits", surely the "edits" go on the edges rather than the nodes of the revision-graph.)

steveklabnik 2y ago
It's trying to point out the common argument that's passed to each command: `jj restore` with no arguments is virtually the same as `jj abandon`, but in practice that means that `jj restore` tends to be called with a file as an argument, and `jj abandon` gets called with a revision (which he's calling edit here). It is in fact a node. The arrows are still just relationships between nodes. > if I'm understanding it right, turns r --[edit3]--> q --[edit2]--> p into r --[edit3]--> p. You are right with the outcome but wrong about why. `jj abandon -r q` would turn `r --> q --> p` into `r --> p`, but you're passing the node as the argument (r is for revision) not the edge. Hilariously, I am literally working on writing version 2 of my tutorial right now, and I'm literally talking about `jj abandon`. What do you think about this? It cuts off where I literally am right now: https://gist.github.com/steveklabnik/71165f9ff5e13b1e95902c45ae8f5320 https://gist.github.com/steveklabnik/71165f9ff5e13b1e95902c4...
- notmywalrus 2y ago
  > > if I'm understanding it right, turns r --[edit3]--> q --[edit2]--> p into r --[edit3]--> p. > You are right with the outcome but wrong about why. `jj abandon -r q` would turn `r --> q --> p` into `r --> p` Well, it can do two things. Given: `r(f3) --[e3]--> q(f2) --[e2]--> p(f1)` `jj abandon -r q` makes `r(f1+e3) --[e3]--> p(f1)`, as if you had rebased `r` onto `p`. `jj abandon -r q --restore-descendants` makes `r(f3) --[e2+e3]--> p(f1)`, as if you had squashed `r` into `q`.

sundarurfriend 2y ago

The biggest blocker for me to switch to using jj currently is https://github.com/jj-vcs/jj/issues/3949 https://github.com/jj-vcs/jj/issues/3949 which is that it doesn't have a `core.fileMode` option equivalent. What this means in practice is that it's unusable from WSL when your repo is on an NTFS filesystem. It gets confused by NTFS's lack of executable permission bit and makes spurious changes/commits. It's a small thing, but while jj adds some convenience, it doesn't add enough (for me) to offset the inconvenience of changing my workflow to not use WSL. (Another relatively minor inconvenience is its inability to use your SSH configs. So if you have multiple key pairs and need to use specific ones that aren't jj's default pick, an ssh-agent is the only way.) That said, I would 100% recommend jj over git for any new programmer who hasn't yet had to contort their brain already into the git ways. All the things that git's UI does a great job of obscuring and presenting in a confusing way, jj presents in a straightforward way that makes sense and is easy to remember.

steveklabnik 2y ago
Ah, I use `jj` on WSL every day, so I was confused at first, but that's because I don't share the drive there any more. That absolutely makes sense as a blocker. The autocrlf bit is a bit of a bummer on Windows, too. > Another relatively minor inconvenience is its inability to use your SSH configs. This should be much better as of last week's release, when you can say "please use git as a subprocess rather than libgit2/gix".
- stouset 2y ago
  > This should be much better as of last week's release, when you can say "please use git as a subprocess rather than libgit2/gix". I understand the decision here from an SSH-support situation, but doesn't this feel like a bit of a step backwards?
  - steveklabnik 2y ago
    It’s just a tough spot to be in: libgit2 has always worked a bit differently than the binaries, gix is incomplete. Ideally gix will be good enough that it could just be used, but things aren’t there yet.

infogulch 2y ago

Is there a short description of how jj works specifically from the perspective of a seasoned git user? I more or less understand git -- how to use it as well as its building blocks -- so the caveats and generalizations and glossing-over that are appropriate for a more general audience seem to get in the way of my understanding what's going on underneath.

justinpombrio 2y ago
This might be what you're looking for: https://jj-vcs.github.io/jj/latest/git-comparison/ https://jj-vcs.github.io/jj/latest/git-comparison/
steveklabnik 2y ago
jj is truly its own VCS, so to deeply understand it, it's more than short. But it does map to git, and so you can sorta explain it in git terms. It's really kind of like "what if you tried to build hg on top of git?" jj is kind of hard to really explain because a bunch of the design decisions have subtle but important impacts on other decisions, so your first impression of a feature may be slightly wrong because you don't get the implications yet. jj is sort of the same as git: you have a DAG of snapshots of your project. The differences are in how you interact with those things. To try and put it in git terms: 1. Commits are mutable, not immutable (but we'll talk about is more later) 2. You're always working in the context of some commit 3. When you modify a file, it becomes part of that commit (we'll talk about the index in a minute) 4. You don't need to care about branches at all, the "detached head" state is the nrom. 5. commits are immutable in the "immutable data structures" sense, in that whenever you modify them, it's almost like you're adding a commit to them. this is why jj calls its "commits" "changes", change IDs stay stable as you edit them, and they produce new git commits for every edit. 6. Because of how this all fits together, you don't need an explicit index; if you want one, you can just `jj new` twice to get two changes on top of each other, and then edit your files. When you have what you want, `jj squash` will move the diff into the parent commit, and now it's "part of that feature" or whatever. If you want `git add -p`, that's `jj squash -i`. That is kind of it on some level, but in reality, it's kind of hard to convey how a few, smaller, more orthogonal primitives let you do everything you can do in git, but easier. (I tried to actively think of cases last night and only came up with two or three that were easier in git than jj, and jj will have fixes for most of those soonish.) stashing is another great example of a feature of git that's just a workflow pattern in jj. There's just... it's a lot. It's hard to know what the best thing really is. Other than `jj undo` :) (I've got this on the brain since I am literally working on my tutorial right now)

wyldfire 2y ago

Does jujutsu have anything like "git am"? I'd like to take a series of patches and jj-ify them so I can play with it. I get that maybe I can't expect to cherry pick a commit because it's naturally different from git. but if I have a patch it seems like I should be able to apply those as jj changes?

KingMob 2y ago
There's no succinct command designed to work with mailed patches yet, but you could mimic it with a little scripting. Maybe something like this? ``` for patch_file in "$@"; do jj new patch -p1 < "$patch_file" author=$(extract_author "$patch_file") commit_message=$(extract_commit_message "$patch_file") jj describe -m "$commit_message" --author "$author" done ```

jjfanboy 2y ago

I love jj and you could pry it from my cold dead hands but I can't make sense of nearly any of these pictograms. :(

bedros 2y ago

Anyone knows of vs code editor extension that works with .jj dir

ilyagr 2y ago
https://www.visualjj.com/ https://www.visualjj.com/ Better link: https://marketplace.visualstudio.com/items?itemName=visualjj.visualjj https://marketplace.visualstudio.com/items?itemName=visualjj...

conradludgate 2y ago

I still don't understand the way jj handles conflicts. If I rebase and then fix a conflict later, are those conflict markers going to appear in some of the commits on github when I push? Maybe I'm in the minority, but I like fixing conflicts as I go. What am I missing?

martinvonz 2y ago
> I still don't understand the way jj handles conflicts. See https://jj-vcs.github.io/jj/latest/conflicts/ https://jj-vcs.github.io/jj/latest/conflicts/. > If I rebase and then fix a conflict later, are those conflict markers going to appear in some of the commits on github when I push? We error out if you try to push conflicts because the Git remote would probably not know how to interpret them. We will probably add an option to allow it later because it can be useful to be able to share conflicts with others if you know that they're also using jj. > Maybe I'm in the minority, but I like fixing conflicts as I go. What am I missing? You can still do that. Hopefully the above answers your question.
- glandium 2y ago
  > See https://jj-vcs.github.io/jj/latest/conflicts/ https://jj-vcs.github.io/jj/latest/conflicts/. Honestly, this page doesn't really make a compelling case as to how checking out the commit with a conflict and amending is better than git rebase/whatever --continue. Overall, it's also quite abstract. Concrete examples would be deeply appreciated.
  - necauqua 2y ago
    It's very obviously miles better because there's no global rebase state?. So you can just leave the conflict there an go work on something else then come back. Also it's not sequential like --continue you've mentioned. Also you can rebase the conflicting commits themselves, and by doing so potentially resolve the conflict and the resolution will propagate. For example manually undoing the rebase while useless (there's jj undo after all) shows that.

khana 2y ago

[dead]

tripple6 2y ago

I've seen several posts on jj, but could anyone please tell what can't be done by git, or what is harder in git but super-easy in jj by providing the sequence of git commands and jj commands for comparison?

martinvonz 2y ago
To move the changes in file `foo` in the working copy into a past commit `X`: `git commit --fixup=X foo; git stash; git rebase -i X^; git stash pop` `jj squash --into X foo`
- Martinussen 2y ago
  That looks more like a git alias than a job for an entirely new tool, to me. How many of the core functions do you really need to cover before `jj` itself becomes redundant?
  - martinvonz 2y ago
    I think you misunderstood. Did you see the list of features? My example is not the only thing jj does.
  - martinvonz 2y ago
    I apologize if my sibling comment sounded harsh. I think you were saying that jj could be implemented as some Git aliases. Given the information available in this thread, that might seem reasonable. I didn't realize that this thread did not include a link to the project's docs. Sorry about that.
- Aissen 2y ago
  You can simplify this: git commit --fixup X ; git rebase --interactive --autostash --autosquash X^ If you do that often, an alias might help; I have one for the second command above. You might want to look at git-fixup or git-absorb for automatically finding the "X" commit. Aside: I really ought to try jj, it looks very promising.

weinzierl 2y ago

I tried to get into Jujutsu several times and tried to love it, but somehow it seems there is little overlap between the issues I have with git (which there are plenty) and the problems jj tries to solve. My impression is that the main motivation behind jj is that Google realized how difficult and costly it is to train all new hires in their internal tooling but did not want to open-source it completely. So they came up with a thin UI layer, made it workable with git as a backend and published it in the hope it will catch on.

bjackman 2y ago
I have no opinion on whether JJ is good but I am pretty confident your impression about the reason for its shortcomings is wrong. Google has a basically tolerable and pretty easy-to-learn Mercurial-based frontend for its bizarre legacy Perforce system. Everything about JJ screams to me that it's been created as the passion project of someone who really wants to build a better VCS, making it compatible with Git was necessary to give it a chance of adoption, and making it compatible with Piper (Google's Perforce thing) was a way to get it funded as a potential benefit to Google. Top-down Google engineering would never produce a project like this IMO.
- oniony 2y ago
  I thought Google moved off of their struggling Perforce server onto their homegrown Piper VCS.
  - bjackman 2y ago
    Piper is an extended reimplementation of Perforce (Piper is piper, expanded recursively. It's so meta, even this acronym)
    - steveklabnik 2y ago
      And while it's not public, jj has a piper backend, so that folks at Google can use jj (This is also why I have some confidence that jj truly is backend agnostic, it has two real backends already.)

globular-toast 2y ago

So jj calls commits "changes", and this is less confusing? Interesting. I find when you dig into people's understanding of git (or version control in general), a lot of them understand it as storing a sequence of diffs. This small thing breaks their understanding of the whole system. Calling them "changes" seems like it would reinforce this belief. Or is that the idea? Does jj embrace this perhaps more intuitive "sequence of diffs" view, but more successfully hide the "sequence of commits" reality?

steveklabnik 2y ago
> So jj calls commits "changes", and this is less confusing? Sort of. It has both changes and commits, actually. (and sometimes commits are called revisions.) jj log @ muzrswxs steve@steveklabnik.com 2025-02-12 10:23:11 85b41b31 │ (empty) (no description set) ○ wotxrwpp steve@steveklabnik.com 2025-02-12 10:23:09 24ce0a16 │ (empty) (no description set) ○ ztxxskuu steve@steveklabnik.com 2025-02-11 18:20:56 1b3e12ac │ run sqlx migrate as part of deploy process ◆ qwovsnvt steve@steveklabnik.com 2025-02-11 17:45:24 trunk b224ca8b │ <redacted> Okay, so muzrswxs is a change ID. It's true that we're connecting changes in a graph, and that that forms history. So in that sense, it's like a git commit. But because changes are mutable (well, the ○ ones and @ are, the ◆ there is not), they are implemented as a sequence of commits. So if you look on the far right there, you'll see 85b41b31 and then below it, 24ce0a16. Below that, 1b3e12ac. These are commit IDs. The first two changes are empty, so what happens if we modify a file? jj log @ muzrswxs steve@steveklabnik.com 2025-02-12 10:28:18 404a73b1 │ (no description set) ○ wotxrwpp steve@steveklabnik.com 2025-02-12 10:23:09 24ce0a16 │ (empty) (no description set) ○ ztxxskuu steve@steveklabnik.com 2025-02-11 18:20:56 1b3e12ac │ run sqlx migrate as part of deploy process ◆ qwovsnvt steve@steveklabnik.com 2025-02-11 17:45:24 trunk b224ca8b │ <redacted> Note that (empty) went away on that head change there, and its change ID is still muzrswxs. But the commit ID has changed from 85b41b31 to 404a73b1. None of the parents changed, of course. We can even take a look at this history: jj evolog --summary @ muzrswxs steve@steveklabnik.com 2025-02-12 10:28:18 404a73b1 │ (no description set) │ M README.md ○ muzrswxs hidden steve@steveklabnik.com 2025-02-12 10:23:11 85b41b31 (empty) (no description set) The evolution log will show us how our change has evolved over time: first we had 85b41b31, then we modified README.d and now we're at 404a73b1. > I find when you dig into people's understanding of git (or version control in general), a lot of them understand it as storing a sequence of diffs. This small thing breaks their understanding of the whole system. I agree with you in some sense, but also, kinda don't. That is, I agree that thinking git stores diffs is not correct, but I'm not fully sold on how big of a deal it is to be incorrect here. And once you really get into things, like, how packfiles are implemented, diffs are present. > Calling them "changes" seems like it would reinforce this belief. Or is that the idea? Does jj embrace this perhaps more intuitive "sequence of diffs" view, but more successfully hide the "sequence of commits" reality? I can assure you that these names are a heated kind of debate internally. I actually said two days ago "hey, so we have changes, commits, and then revision as a synonym for commit. shouldn't commit be a synonym for revision? because 'revision' is kind of an abstract idea, but 'commit' is git-specific, so like, I think it should be "we have changes, and changes have revisions, but the git backend implements revisions as commits" and that thread is still going this morning, with links to many previous discussions. Someone even wrote a blog post a year ago https://blog.waleedkhan.name/patch-terminology/ https://blog.waleedkhan.name/patch-terminology/ jj is still figuring out how best to present its ideas. I really like "change and revision" to describe these two things, but a lot of folks are concerned that "change" is too generic and is hard to figure out, that is, when I said this above > its change ID is still muzrswxs. But the commit ID has changed This is two different uses of the word "change". Is that confusing? Maybe. Is it confusing enough to find another word? Not sure.

geenat 2y ago

Auto-commit of large files and no way to un-bloat your repo is a showstopper for me no matter how good the DX might be. Large file handling needs to be sane in any new VCS, IMHO, as this is a main failing of git (..without the extra legwork of git-lfs). Edit: https://github.com/jj-vcs/jj/issues/80 https://github.com/jj-vcs/jj/issues/80 Could maybe bring jj up to parity with git here

aseipp 2y ago
Large file handling has improved in recent versions, FWIW; large files are left untracked if they violate the size limit (no auto track), you have to selectively add them at that point. Note that you can unbloat your local copy by pruning the operation log and then running jj gc if you accidentally add blobs and stuff; though if you push the blobs somewhere you obviously can't undo that so easily, that's no different than Git. Git's underlying storage format just isn't a very good fit for any kind of "large-ish file" storage; Git LFS is mostly just hack and it is unlikely to be supported anytime soon. Our hands are a bit tied on that front. My impression is that most of the interest and momentum for solving the "large files problem" would preferably be invested in a native non-Git backend for Jujutsu.

deleted 2y ago

[deleted]

mystickphoenix 2y ago

Something that I've been struggling to wrap my brain around is: 1. Can I use jj inside a repo that was already initialized with git? I think the answer is yes, but I haven't found a tl;dr for it. 2. What does the workflow look like to use jj on an existing git repo that all of your coworkers use git for?

steveklabnik 2y ago
> Can I use jj inside a repo that was already initialized with git? Yes. > What does the workflow look like to use jj on an existing git repo that all of your coworkers use git for? I struggle a little to answer this because on some level, the answer is "whatever you'd like it to be." That is, from your co-workers' perspective, nothing changes. You push some changes up to a git repo, they have no clue you used jj to do it. But I also feel like that maybe isn't answering your question.
- mystickphoenix 2y ago
  I suppose what I'm looking for is maybe a translation from git to jj from the perspective of working in a repo with other users that are using git. Something along the lines of: 1. init jj in an existing git repo 2. instead of branching, do x, y, z 3. instead of committing after changes are done, do x, y, z 4. when pushing, do x, y, z 5. if someone else pushes to the same branch, here's how to handle it 6. if someone rebases and force pushes the branch, here's how to handle it 7. if you have merge conflicts, here's how to handle that I think I'm having a hard time trying to grok the jj "mental model" while simultaneously understanding how it translates to an existing git repo. I suspect for jj to get traction outside of single devs or companies that use jj exclusively, some extra focus in the docs giving guidance in the liminal space between would be super helpful.
  - steveklabnik 2y ago
    Ahh, I see, thanks. > some extra focus in the docs giving guidance in the liminal space between would be super helpful. I'm working on this! https://steveklabnik.github.io/jujutsu-tutorial/real-world-workflows/intro.html https://steveklabnik.github.io/jujutsu-tutorial/real-world-w... describes the most basic two workflows for 2-3. https://steveklabnik.github.io/jujutsu-tutorial/sharing-code/intro.html https://steveklabnik.github.io/jujutsu-tutorial/sharing-code... tries to explain 4-6 (but isn't as complete as it should be), and there's an unwritten place for 7 to exist in the future. I don't think these things are perfect yet, and I'm actually re-writing the whole thing, and it's going to focus on exactly these things, and there's interest in upstreaming the whole thing. That is partially why I asked, because I'm trying to make it so that these things are more easy for you in the future :) So I do really appreciate the answer.

159jonie158 2y ago

ROBLOX BLOX FRUIT

159jonie158 2y ago

[flagged]