Jujutsu at Google [video] (opens in new tab)

It's Google. They are professional foot-shooters when it comes to making their offerings accessible to their audience.

This seems similar to the "Local History" feature in JetBrains IDEs.

Git rebase works fairly well and is somewhat uneventful, unless there are major changes happening. I do hate the experience when one file was remove in my feature branch, but main did a major refactor which affected the original file, so conflicts are a bit awkward then - but other than that, this seems like a fairly clean workflow.

I think what people usually mean is "scary" or "it's easy to mess up". Git is very easy to use until you mess up, then it can become complicated, and certain actions may have devastating consequences.

Two examples from recent memory:

Someone merged the develop branch into their branch, then changed their mind and reverted the merge commit specifically (i.e. reversing all the incoming changes), then somehow merged all of this into the develop branch, undoing weeks of work without noticing. I had to go in and revert the revert to undo the mistake. Yes they messed up, but these things happen with enough people and time.

Another very interesting issue that happened to a less technical person on the team was that their git UI somehow opened the terminal in the wrong folder. They then tried to run some command which made git suggest to run 'git init', creating another git repo in that wrong location. Fast forward some days and we had an issue where people had to clean their repos, so I was in a call with the person helping them run the clean command. The UI opened the wrong location again, I helped them put in the command and it started cleaning. The problem was that this git repo was essentially at the top level on their disk, and since was a fresh repo every single file was considered a new file so it tried to delete EVERYTHING on their disk. This was of course mostly my fault for not running git status before the clean command, but this potential scenario was definitely not on my mind.

I am (was) a git expert. I’ve written a git implementation. I’ve used it since shortly after it was first announced.

Git has lots of sharp edges that can get hairy or at least tedious really rapidly. You have to keep a ton of random arcana in working memory at all times. And a bunch of really useful, lovely workflows are so much of a pain in the ass that you don’t even conceive of doing them.

I learned jj in one day and never went back.

So based on my experience teaching git ( I remember a cvs to git migration …) , reality tells me people find git difficult.

Now, once you teach them it’s a commit graph with names, some of them floating, some people get it.

The thing is, not everyone is comfortable with a commit graph, and most people are not - just like people get lists and arrays but graphs are different.

So I agree with you on principle ( it shouldn’t be difficult), but most people don’t have a graph as a mental model of anything, and I think that’s the biggest obstacle.

I have burned git into my brain, so it's no longer hard to me. OTOH, I only pull out jq once every six months or so, and I just barely scrape by every time.

From time to time, I end up in a state which I don't know how to recover from, and it's very frustrating to have to take an hour or two from my real work in order to try to figure out how to get out of that state.

https://roadrunnertwice.dreamwidth.org/596185.html

I've worked with many folks over the years after learning myself...

The feeling of complexity comes from not yet understanding that commits are just sets of changes to files. They are then thrown off the scent by new terms like origin clone vs push and pull, merge vs rebase, HEAD increment notation vs other commit hashes.

Once people start with a local understanding of using git diff and git add -p they usually get the epiphany. Then git rebase -i and git reflog take them the rest of the way. Then add the distributed push and fetch/pull concepts.

Parsing json is so much easier with Python than jq, it's not even funny. That doesn't mean jq is useless, because sometimes keeping it in the shell is the best option. But in terms of ease of use jq is shit.

I think people who grasp the basic idea of a commit graph and approach it in terms of "this is how I want to manipulate the graph, what are the tools that will allow me to do this?" find it easy, and people who approach it in terms of building a cookbook of commands that comprise a workflow don't.

Even though I never found git hard, I find jj better.

My perspective, git isn't hard, but coordinating git workflows in teams with a merge backlog is a real pain in the ass.

I've long been facinated by how bimodal understanding of git is. I'm one of the lucky ones to whom it came naturally, but there's clearly a large population who finds git challenging even after investing significant time and effort into learning it.

I don't see this anywhere nearly as drastically with other tools.

that's okay, it doesn't need to be your personal experience. you just need to understand that "git gud" is not a sustainable or intelligent mantra for tool design and selection

What if we don't use git rebase at all? What does jj have to offer us?

I don’t understand this critique. You can copy a .git folder around just fine. You can expose a “server” by giving friends ssh keys that can only access the git stuff. In fact for a long time that’s how git “was done” at various corps.

Git server is just a directory. It may or may not have actual content files in it (aka bare). In fact, any git clone of any repository is also a server on its own (and clients can have multiple "remote"s to pull from).

My go-to solution for this problem is a git init --bare --shared=group repository in a shared mountable drive. Then you can declare that repo origin, and tada, git push/pull works.

> terabytes of source code

You sure that exists?

Git repositories that contain terabytes of source code?

I could imagine a repo that is terabytes but has binaries committed or similar... But source code?

I appreciate your frank oppenness to feedback! I'd like to give you some, but first I want to call out that (1) I'm certainly no expert and (2) you may have been voluntold to make a powerpoint on material that isn't well-fit for powerpoint.

My feedback:

- I think you could improve by being more excited / exciting (the Death By Powerpoint slide deck says "passionate"). Personally, I try to mitigate this problem by drinking coffee shortly before I'm expected to be engaging. It is a drug, and for me it works.

- You could also draw the main impactful points out of the background info. The presentation you give here has a lot of deep technical detail, which is certainly of interest for the correct audience, but I think generally fits poorly in a powerpoint presentation. I think you'd generally want to focus on more high-level performance characteristics, or particularly interesting details. Perhaps a 3-4 page document would be better for this sort of deep technical material. Or maybe the level of detail is actually perfect, and I'm just not the correct audience.

I really love your response here. You seem like a great person, I think your coworkers are lucky to have you.

The thing to change: realizing time your audience spends reading your slides is not spent paying attention to what you say.

If you struggle with being engaging, then you want even less text on each slide so that the audience doesn't get an additional reason to tune you out.

I think GP is suggesting using less words on a slide, having visual aids and often, thinking of 2-3 ideas that someone would remember from your presentation. To the first point, if you take more than 1 min on a single slide, you need to split it into more slides.

Also, present things that you are passionate about if you want to make people care about your presentation.

The two pieces of advice I remember for a WWDC-style talk are

1. You haven't practiced enough. Practice more.

2. If you think you're talking too slowly, slow down even more. (Can't tell you why it's worded like that.)

Thanks for presenting. I was a fig lover so this area is interesting to me.

This is a really hard topic since it's hard to understand the significance of the jj contributions without explaining a ton of internal details like Piper, CitC, TAP, blaze, etc. I think you struck a good balance here.

I don't think you need to "be more engaging" or be more passionate, and when people say that, it indicates they aren't engaged, but it's not a useful suggestion of how to improve.

I think the main issue was that on just about every slide, I found myself wanting to read ahead on the slides instead of waiting to listen to you talk. There are a couple factors to this:

1. Impatience. I want to ingest information faster. Believe it or not, the "talk slowly" advice is usually not good for a technical talk with decent acoustics. E.g. listen to a talk by Bryan Cantrill and notice how fast he talks while still being clear. Rehearsal helps, but if you simplify your slides, you can also make them easier to perform. Listen to a random slide in your video and notice how much time is filled with silence or filler words.

2. Scanning the slide because I'm unsynchronized with the speaker. E.g. if everything you say isn't clearly correlated with the content of the slide in a linear way, then I have to scan the slide to attempt to "resychronize" and figure out what bullet you are on. Sometimes presenters don't want to read the bullets verbatim, which makes it difficult to match up the spoken language with the written language, whereas if you said the first word in a bullet, I could quickly seek to that line. Skipping bullets also causes this, especially at the end of a slide, since then I want to try to read all the bullets on a slide ahead of you in case you decide to skip them in the future.

Fewer bullets per slide and fewer words per bullet help with both of these. Aggressively cut or summarize material so you don't have to skip over anything (e.g. instead of listing 6 jj piper commands and only talking about 2, list just 2 and write the number of total commands e.g. "we added 22 subcommands including mail and submit"). Put extra material (if any) in an appendix after the end if you think you might have extra time or want to use it for Q&A. Rehearse until you can belt out what you want to say on each slide without fillers or pauses (and record yourself so you can tell how much you are doing this). When I'm sharing my screen, I actually like to point my mouse cursor at the bullet I'm on so nobody has to guess where we are, but sometimes that's not available.

Your first slides essentially teach the audience how to consume your talk. E.g. a good pattern is if (1) all your bullets are short (2) you read every bullet verbatim, elaborate on that bullet for a bit, and then repeat on the next bullet. If you stick with a pattern like that, then your audience knows how to follow along. Other patterns work too.

I'm sorry this wasn't shorter and I hope it's helpful.

Again, amazing to be seeking feedback (or open to it). I'm at minute 13 (code review management / bookmarks, etc.), and will give my feedback from there:

https://www.essayselevate.com/post/how-to-structure-a-winnin...

"SCAR", which I learned as "Situation, Consequences, Actions, Results" but the above essay will let you go deeper.

Bad: "Two people stood up there, said a few words, and then everybody had cake and went home"

Good: "The situation was... it was a beautiful venue, everybody was dressed nicely, there was music, a slow walk. What these two people were doing was going to bond them together for the rest of their life (or until they had an ugly divorce, whichever came first). They gave a great speech that they'd been practicing all morning in the mirror, gave each other a kiss and a ring to seal the deal, then everyone had cake, danced, and went home tired but happy!"

...this is obviously (hopefully!) exaggerated, and there's a whole bunch more fluffery in the 2nd than the first but imagine this:

1) The situation is that google on perforce or git was dog slow and blah blah not designed for the scale of our monorepo, etc.

2) The consequences was reduced development velocity and increased errors in prod b/c people were trying to bypass CI/CD steps b/c everything was so slow

3) We introduced CitC / Cloud Commits, and => {your technical brilliance described here...}

4) ...and the result was butterflies and rainbows, and here's a graph that shows the production incident rates going down and the changelist rates going up after we GA'd `jj` on linux.

5) The End!

As it stands, much of the presentation is #3 but you're not even giving yourself the credit of bragging about how you discovered the problem (challenge) and the cleverness that went in to inventing your solution.

re: bookmarks:

"We often had people mailing around patches -or- Sometimes PR's were tough to review due to ... -or- I've always wanted an easy way to ..."

=> "Without good bookmark support [adoption would suffer|it would be seen as a step back|collaboration wasn't instant|...]"

=> "So I built bookmarks for `jj`, they work like ..., and solves most of the problem"

=> "It's [better|faster|cheaper|quicker|more fun] than [GitHub|Our Old System|getting yelled at by Linus Torvalds|...etc..."

=> "The IMPACT of bookmarks is: ..." => "It IMPACTED the technical bits here: ..." => "The USER IMPACT is: ..." => "...and finally the business gets: ..." => "What a powerful impact!"

I'd _LOVE_ to see you run a breakdown of any kindof arbitrary slide in the deck and post a deconstruction in this format as kindof a practice/workshop.

It's very OK if (at first) it's pretty mechanical! It's just super-helpful to basically "disassemble" what you're trying to talk about in this mechanical way, and then you can take the proper bits and put them back together.

Situation => Consequences (or Challenges) => Actions => Results => IMPACT!

If you just string a bunch of technical details or technical choices together, you're missing the whole "compelling story" that exists. Even if you just "set the stage" with a single "Situation" slide at the beginning, and a single "Results/Impact" slide at the end... each interior "loop iteration" can be easily set up with a short "Challenge/Consequence" & "Action/Detail/Choice"

"Git + Monorepo was yuck!" => [ "Slow FS" + "CitC" ] => [ "Big Checkouts" + "VFS" ] => [ "Branches?" + "Chose `cp $FILES branches/*` ; Feedback?" ] => "JJ has been well accepted and has a bright future, inside and outside of el-goog!"

Not parent but I think the link is pretty clear about what they want to say. I haven't got the time to actually watch the full video, but I could tell this is not a great presentation just by randomly clicking at random timestamps. And almost any presentation from Google (technical or not) I watched on YouTube is better than this.

If you really want me to explain it for you, and just one issue:

There are way too many words on your slides.

P.S. You should click that link and go through it again. If you still don't get it, try once more.

If you don't care about the material, why on earth would anybody sit around for 15 minutes/30 minutes/an hour listening to you talk about the material. The sole reason for a presentation over a technical reference buried somewhere is because the presenter wants the audience to care about the thing they're presenting. If that isn't reflected in the presentation, it's not a worthwhile presentation.

I disagree, but it doesn’t mean you’re wrong - we might just be looking for different things.

My view is that if you’re going to talk like a bored robot, then I need a transcript or a paper which is much shorter than a talk. I distinctly remember not going to classes at university because the teachers wouldn’t give me anything beyond reading a book aloud. I just read the book at home.

Now, if you’re able to indicate what’s important and not important, what’s interesting and what isn’t , and why you like it , I’ll be delighted to watch your talk.

I think it’s very difficult to be interested in something new if the presenter doesn’t seem to care about it. This is different from something written , where I expect something dry anyway.

The irony the deck presents 3 very different presenters to show that you don't need to be Tony Robbins to be passionate.

If you can't be passionate, don't make it a presentation. Passionate doesn't need to mean over-the-top, but it means speaking on the topic effectively and in a way that reflects believing there's a reason for these people to sit there and listen to you.

No one is forcing people to do presentations, but once you put people in a situation where they're expected to give you their undivided attention for a block of time, those are very reasonable table stakes.

There's always blog posts, articles, mailing lists, HN posts, etc. if you don't believe there's a strong need for people to set aside time consume your information in the form of a presentation.

"passion" here means "be excited about the subject", which usually (neurospicy people exluced naturally) automatically brings up feelings from the speaker in a "this is cool and I want to share it" kind of way.

If I want to listen to someone read a slide deck word for word in a monotone voice, I can have an AI do it. I'd much rather read a blog post at that point though.

If there's zero passion in it, just write a fucking blog article; don't waste my time with a presentation.

Because it's nicer tool to use. To borrow someone else's descriptions (paraphrased), it's simultaneously simpler than git and more powerful than git. Some things that were a source of friction in git (e.g. any non trivial rebase) just stop being so.

Easier CLI, deferred conflict resolution, megamerge workflow, an "undo" command which is like a gift from the gods.

Here's what I wrote about it eight days ago: https://news.ycombinator.com/item?id=45673808

Lots of other opinions in that thread too.

auto rebase, simple undo (jj undo), no staging area, easy splitting and merging

Because you work for Google, or because you don't want to wait for official git to be rewritten in Rust.

So if I push a commit update, and then someone else pushes a commit to one I build on, and there is a conflict...

How does recording the conflict, but not introducing it (if I'm understanding correctly), ... how does this affect my build/ci workflow?

> But you're kind of fighting against the grain to do it.

> `jj absorb`

git absorb exists.

Having used git submodules, I see a lack of them as a feature. I honestly think that a script that checks out a specific commit from an external repository, combined with adding the path to the .gitignore is strictly better than submodules.

LFS sorta works and submodules are just managed by git, and you can create tags with the git CLI just fine.

Hooks are a bigger change, though, for sure.

Furthermore, many engineers at Google work on Macs, some even on Windows, but the actual code runs on a Linux box in a datacenter. I use a Mac, my editor is local, my terminal is local, but it's all SSH/remote to the linux box, so I've never needed jj to run on my Mac. This, or a high powered Linux desktop, are the norm.

The main exceptions to this are devs who work on iOS or macOS software, who will sometimes do local builds on their physical machine. They would benefit from jj support, but there are more hoops to jump through, and the jj port will most likely be less about running on macOS and more about jj supporting the weird ways in which source is accessed.

Not that there are any other options. You're not gonna run datacenters on Mac boxes or Window s, nor would you want to pay a Unix vendor

Yes, as in anyone can use it, you don't need special permission.

It does require a google CLA.

it is literally impossible to contribute to jj without a Google account and a signed agreement with Google.