Live data from Hacker News

Jujutsu at Google [video]

youtube.com

141–150 of 212 posts

Re: Jujutsu at Google [video]

#141

Earlier quoted context omitted.

git doesn't do everything that SVN does, so I don't think that's true.

The development world is much different and entrenched than it was when the move from svn -> git happened. Think of all the tooling, integrations, and automation we use these days. That was not happening 15+ years ago. I don't think svn as an analogy holds much water, tbh

Tooling, integrations, and automation (Including CI) were all things we used at my work when we switched from CVS to SVN almost 20 years ago.

Re: Jujutsu at Google [video]

#142
post #16
post #5

Off topic, and I don't want to knock the presenter here, but if you're ever going to give a public talk or presentation at work _please_ review the Death By Powerpoint slide deck[0] first. [0] https://www.slideshare.net/slideshow/death-by-powerpoint/855...

Ugh, I'd prefer people keep passion for the bedroom and just convey information straightforwardly without trying to "sell" it to me. Adding a false excitement signal to the information is a hindrance to me as a viewer. If you want Tony Robbins then go and see him. If you want an overview of the new product architecture lets keep calm and get on with it.

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

Re: Jujutsu at Google [video]

#143
post #81

Earlier quoted context omitted.

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.

There are simply people who've rtfm and people who haven't

Quick, what does git pull foo do if foo is a branch vs a remote and how do you fix it if you messed up/which is preferred when both exist?

Re: Jujutsu at Google [video]

#145
post #95
post #18

I've worked in huge repos with hundreds of developers pushing code every day, dozens of MRs open per day, and all I always needed was a very limited set of what git is capable of (git commit, git co, git st, git merge/rebase, git log). To find bugs, I use "bisect but visually" (I usually use jetbrains IDEs, so I just go to the git history, and do binary search in the commits, displaying all the files that were affect…

The biggest for me: merge-conflict as first-class state within JJ. I regularly have multiple commits being worked on at a time across different parts of the codebase. If I have to sync to head (or any rebase) and one of my side branches that I'm not actively working on hits a merge conflict, I don't have to deal with it in that moment and get distracted from my work at hand (ie: I don't need to context switch). This…

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

Re: Jujutsu at Google [video]

#146
post #5

Off topic, and I don't want to knock the presenter here, but if you're ever going to give a public talk or presentation at work _please_ review the Death By Powerpoint slide deck[0] first. [0] https://www.slideshare.net/slideshow/death-by-powerpoint/855...

Thanks for the link. I went through it but I'm not sure what it's telling me to change. Can you elaborate? If it's "be more engaging", i think is unfortunately going to be hard to improve because this is just how i am.

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.)

Re: Jujutsu at Google [video]

#147
post #28

Earlier quoted context omitted.

> 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?

Google had 86TB of sourcecode data in Piper way back in 2016.

Dang, that's mind boggling - especially if I keep in mind that a book series like lord of the rings is mere kilobytes if saved as plain text.

Having 86 TB of plain text/source code - I can't fathom the scale, honestly

Are you absolutely sure there aren't binaries in there (honestly asking, the scale is just insane from my perspective - even the largest book compilation like Anna's isn't approaching that number - if you strip out images ... And that's pretty much all books in circulation - with multiple versions per title)

Re: Jujutsu at Google [video]

#148

jj has been fantastic for my productivity, but most of that comes from its alignment with the particular SWE practices on my team: trunk-based development, small atomic commits, quick review turnaround. Getting rid of the staging area and allowing conflicts are the biggest wins for me day-to-day. No more stashing/popping or littering my workspace with WIP commits. It's so easy to whip up a change, send it for review,…

Wait, what? I’ve spent maybe 10 minutes on a jj tutorial but got distracted. Yours is the kind of anecdote that makes me want to jump back in and push ahead.

Re: Jujutsu at Google [video]

#149
post #125

Earlier quoted context omitted.

The git documentation is one of the nastiest docs ever just like the whole git ui. It’s technically entirely correct, but won’t help you understand how it works in any way. It’s exactly like folks in 1995 telling you to rtfm when you’re trying to install Linux from a floppy disk. It’s doable, but annoying, and it’s not that easy.

That's really unexpected. To me, git documentation was one of the best cleanest official docs I've ever read. Just in case, I'm talking about the Pro Git book [0]. I remember reading it on my kindle while commuting to office by train. It was so easy to understand, I didn't even need a computer to try things. And it covers everything from bare basics, to advanced topics that get you covered (or at least give you a goo…

This is exactly what I meant. https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-N...

The book says that ‘ To really understand the way Git does branching, we need to take a step back and examine how Git stores its data’ then it starts talking about trees and blobs.

At that point you’ve lost almost everyone. If you have a strong interest in vcs implementation then fine, otherwise it’s typically the kind of details you don’t want to hear about. Most people won’t read an entire book just to use a vcs, when what they actually want to hear is ‘this is a commit graph with pointers’.

I agree with you : the information is there. However I don’t think you can in good faith tell most people to rtfm this, and that was my point.

Re: Jujutsu at Google [video]

#150
post #83

Earlier quoted context omitted.

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.

Git rebase is an enormous pain in the ass. Rebases must be done linearly. And right now ! Oops, you made an error in an earlier stage of the rebase? Start over, good luck! Want to check something from earlier while you’re in the middle? Sorry, you’re in a modal state and you don’t get to use your regular git tooling.

git has rerere for this usecase, jj doesn't - you have to find the conflict resolution manually in your history in this case if you made a mistake.
Post reply on HN