Jujutsu at Google [video]

The git mental model is more complex than cvs, but strangely enough the docs almost invariably refer to the internal implementation details which shouldn’t be needed to work with it.

I remember when git appeared - the internet was full of guides called ‘git finally explained ‘ , and they all started by explaining the plumbing and the implementation. I think this has stuck, and does not make things easy to understand.

Please note I say all this having been using git for close to 20 years, being familiar with the git codebase, and understanding it very well.

I just think the documentation and ui work very hard towards making it difficult to understand .

Just basically flip the first two bullet points:

Situation: "Our repo shape can assume: ..."

Consequences: "Non-mainline graphs fit in memory ..."

Actions: "Tada! Revset engine!"

Result: "Monotonic commit numbers"

Impact: "b/c we can sort ranges => unlocks filtering, client-side processing, etc"

(please excuse my poor understanding of the DETAILS of `jj-at-goog` internals, so I'm butchering some of the details of impact, etc).

...another comment mentioned "death by powerpoint". You can still do/make your slides as you're currently doing it, but when you're "done", just move all the text down into the "speakers notes", and focus on providing some illustrations or comparisons for the visual portion.

Example here: https://share.google/images/tWSmujLgnX2gDvtgL

On the revset, a bunch of it could be helped by "illustrating the impact" or "compare and contrast"

     | RevSet         |  Git-on-ext3   |
     +----------------+----------------+
     | Indexed        | FS-Traversal   |
     | Working Memory | Disk Cache     |
     | Strong Server  | Local Limits   |
     | 456 > 123      | $RAND != $RAND |
                  ...etc...

You're so deep in the weeds it's like asking a fish what they think about water (and to clarify: I'm absolutely not meaning this in any sort of insulting way)... it's just that when you're communicating to others, you may have to end up moving "back and forth" or "up and down" ... illustrated: https://www.youtube.com/watch?v=3amL4O8BSAg ... stretching things out so you can see the individual threads then putting them back, or giving them a twist and blending in a new topic.

Because of your intimate familiarity with the inner workings, sometimes in your talk you're describing an inner working (ie: there's 206 bones in the human body!) but there's no context about what makes that better, or worse, or how they're conceptually connected with each other.

On the grand scale, what is the IMPACT you want your talk to have? To put words into your mouth: "We're about to go GA at google, which is a big deal."

How do you get there? Where did you start from? To put words into your mouth: "JJ is solving google-scale problems, and there's _demand_ and _support_ for bringing it about." [that's your situation]

Consequences? Actions? => now you have set the scene for your very same technical deep dives on JJ.

1) Google has big problems, JJ is solving lots of them!

2) The consequences of (jj-solving-them) or (suffering-further-with-git) are: ...

3a) The actions that have helped jj forge ahead (better than git) are: ...

3b) The actions that jj reduces suffering compared to git are: ...

4) ...as a result, we're about to go GA

5) The impact is increased community trust, improved internal development capabilities, etc...

...again: it's _mostly_ about rearranging things, and providing a little bit more context so that what you _are_ presenting hits your audience better. (3a and 3b are kindof what your current presentation was all about... just set it up a little more on how those interact with the larger picture)

Situation: You've done a great technical thing, and are being asked to present more and be an advocate for it (and yourself)

Consequences: ...if people don't understand JJ, there will be less adoption, or people that would be well-served by it won't use it, or won't contribute

Action: ...you're taking feedback on presentation skills, will continue your systematic learning and iterative improvement approach to this tech-adjacent skill

Result: Butterflies! Rainbows! 150% increase in JJ contributors and 5000% increase in JJ adoption... world peace imminent! :-P

<3 ... best of luck, and free free to reach out if you'd like to continue the conversation!

Yes. I think that this difference is what introduces a lot of friction, both in the model, and how people use it. The divergence between the files that exist on disk inside your working copy and what's actually tracked means lots of opportunities for friction that go away once you decide that it should. That doesn't mean things are perfect, for example, by default jj only snapshots the filesystem when you run a `jj` command, so you can still lose changes from in between those, you need to enable Watchman to get truly full logging here.

> all these states occur in the reflog.

Well, let's go back to the documentation for reflog:

> Reference logs, or "reflogs", record when the tips of branches and other references were updated in the local repository.

It only tracks changes to refs. That is, the states that refs have been in. So, one big example is detatched HEADs: any changes you make to those, which still are contents of the repository, are not tracked in the reflog.

Even for refs, there's differences: the reflog says "ref was in state x and changed to state y" without any more details. jj's oplog keeps track of not only the state change, but the reason why: "rebased commit with these args: jj rebase -r -d trunk"

The reflog only tracks individual refs. Say we rebase multiple commits. The reflog still just says "the head of this branch was in state x and changed to state y" but the oplog says "a rebase happened, it affected all of these commits refs in these ways," that is, it's just inherently more rich in what it tracks, and does it across all relative commits, not only the refs.

This doesn't mean the reflog is bad! It's just a very specific thing. Git could have an operation log too, it's just a different feature.

1. We're rewriting some commits. Let's say a chain of commits A through G. We want to make some change to commits A and D.

2. As we're editing commit D, we realized that we need to make some changes to B to match the updated A.

3. Also while editing D we realized that we want to take a look at the state in A to see how something worked there.

With jj, here's what I would do:

1. Run `jj new A`, make the changes, then `jj squash` to squash the changes in to A and propagate them through the chain.

2. Run `jj new D` to make changes. We now notice that we wanted some changes to go into B. We can make the changes in the working copy and run `jj squash --into B -i` to interactively select the changes to squash into B.

3. Run `jj new A` to create a new working-copy commit on top of A, look around in your IDE or whatever, then run `jj edit `. Then run `jj squash` to squash the remaining changes in the working copy into D.

I think you know the steps to do with Git so I won't bother writing them down. I find them less intuitive anyway.

    $ git checkout HEAD
    $ git commit --allow-empty -m "_"
    $ git checkout master
    $ git reflog
    a91 (HEAD -> master, origin/master, origin/HEAD) HEAD@{0}: checkout: moving from b94 to master
    b94 HEAD@{1}: commit: _
    28d (origin/feature, feature) HEAD@{2}: checkout: moving from feature to @

> The reflog only tracks individual refs. Say we rebase multiple commits. The reflog still just says "the head of this branch was in state x and changed to state y" but the oplog says "a rebase happened, it affected all of these commits refs in these ways," that is, it's just inherently more rich in what it tracks, and does it across all relative commits, not only the refs.

    68e HEAD@{15}: rebase (finish): returning to refs/heads/feature
    68e HEAD@{16}: rebase (pick): message #6
    7ff HEAD@{17}: rebase (pick): message #5
    797 HEAD@{18}: rebase (pick): message #4
    776 HEAD@{19}: rebase (pick): message #3
    c7d HEAD@{20}: rebase (pick): message #2
    f10 HEAD@{21}: rebase (pick): message #1
    c0d HEAD@{22}: rebase (start): checkout @~6

    a7c HEAD@{100}: rebase (reword): message ...
    3b1 HEAD@{229}: rebase (reset): '3b1' message ...
    4a4 HEAD@{270}: rebase (continue): message ...