[HN Gopher] Jujutsu at Google [video]
___________________________________________________________________
Jujutsu at Google [video]
Author : Lanedo
Score : 109 points
Date : 2025-10-30 13:00 UTC (9 hours ago)
(HTM) web link (www.youtube.com)
(TXT) w3m dump (www.youtube.com)
| Lanedo wrote:
| The full JJ Con playlist is:
| https://www.youtube.com/playlist?list=PLOU2XLYxmsILM5cRwAK6y...
| rs186 wrote:
| I find it interesting that the video itself is unlisted.
|
| So do they want people to watch this or not?
| Centigonal wrote:
| It's Google. They are professional foot-shooters when it
| comes to making their offerings accessible to their audience.
| Svoka wrote:
| Thanks for this!
| barlog wrote:
| FYI: Linux only GA planned for early 2026
| kyrra wrote:
| This talk is focused on JJ within Google.
|
| This is a Google-internal only GA. JJ is available externally
| just fine. Google is mainly a linux-dev shop, with all other
| platforms being second-class citizens.
| Ferret7446 wrote:
| 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
| phyrex wrote:
| The datacenter OS doesn't have to be the same as the
| developer OS. At my work (of similar scale) the datacenters
| all run Linux but very nearly all developers are on MacOS
| shadowgovt wrote:
| MacOSX is a popular choice for dev boxes (if I understand
| correctly, they provide some pretty good tooling for
| managing a fleet of machines; more expensive hardware
| than a Linux dev machine fleet, but less DIY for company-
| wide administration).
|
| ... but Google solves the "A Linux fleet requires
| investment to maintain" problem by investing. They
| maintain their own in-house distro.
| skirmish wrote:
| > their own in-house distro
|
| Not really, it is just a well known outside distro plus
| internal CI servers to make sure that newly updated
| packages don't break things. Also some internal tools, of
| course.
| shadowgovt wrote:
| Relative to what the rest of the world does, that _is_
| maintaining your own in-house distro.
|
| It's downstream of Ubuntu (unless that's changed) but
| it's tweaked in the ways you've noted (trying to remember
| if they also maintain their own package mirrors or if
| they trust apt to fetch from public repositories; that's
| a detail I no longer recall).
| qalmakka wrote:
| > UNIX vendors
|
| Well FreeBSD exists, just look at Netflix
| metabagel wrote:
| What does "GA" stand for? General availability?
| steveklabnik wrote:
| Yes, as in anyone can use it, you don't need special
| permission.
| spyspy wrote:
| 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...
| martinvonz wrote:
| 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.
| BoorishBears wrote:
| 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.
| pinkmuffinere wrote:
| 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.
| martinvonz wrote:
| Thanks!
|
| The presentation was mainly for the audience that was
| present at the conference, which was mainly people who have
| used jj for a relatively long time, so I think part of the
| problem is just a mismatch between audiences there and on
| YouTube.
|
| I agree about being more exciting. Not sure how to improve
| that :P I drink too much coffee all the time that I don't
| notice any difference. Harder drugs, perhaps :)
| rs186 wrote:
| 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.
| redleader55 wrote:
| 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.
| martinvonz wrote:
| Putting less details on the slides is something very
| actionable. Thanks.
|
| > Also, present things that you are passionate about if you
| want to make people care about your presentation.
|
| Haha, this topic is something I'm very passionate about.
| That's how I look when I'm excited :)
| Y_Y wrote:
| 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.
| BoorishBears wrote:
| 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.
| phainopepla2 wrote:
| > No one is forcing people to do presentations
|
| To the contrary, pretty much every presentation I've ever
| given has been one that I would not have done if it were up
| to me
| BoorishBears wrote:
| Ah sorry, I gave way too much credit to the reader.
|
| Please do continue to give bad presentations and insist
| it's just not in you to do better.
| cwillu wrote:
| Ironically, that slide deck is pretty insufferable.
|
| Yes, lets pretend "make *meaning*" is a meaningful thing to
| say, when compared to "I'm required to do this" or "I have
| information to convey"
| Cyph0n wrote:
| Good advice for presenting a TEDx talk. Bad advice for a
| technical talk.
| OkayPhysicist wrote:
| 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.
| Cyph0n wrote:
| But this was a technical presentation at a conference
| dedicated to the technology in question. A person stumbling
| across this on HN does not magically make them part of the
| target audience.
| OkayPhysicist wrote:
| A technical presentation is a still a presentation, as
| opposed to a reference document. If you want to give
| someone a block of technical information, you do so in a
| reference document. You talk in front of a room full of
| people in order to convince them that this matters enough
| to bother.
| Cyph0n wrote:
| Sure, but I don't think this is relevant to the comment
| thread we're in, which started off by sharing generic
| advice that mostly applies to TED-style motivational
| talks or "keynotes" at large conferences etc.
| OkayPhysicist wrote:
| I definitely thought we were downstream of
| pinkmuffinere's critiques about not establishing a reason
| to be excited about the material. oops.
| skeptrune wrote:
| I love this. Will review my presentations by this standard in
| the future haha.
| crtasm wrote:
| >Jujutsu, aka JJ, is an open-source, Git-compatible VCS
| oofbey wrote:
| Thanks for that context. Why would I want to use it instead of
| git?
| stonogo wrote:
| Because you work for Google, or because you don't want to
| wait for official git to be rewritten in Rust.
| jeffbee wrote:
| As I recall, git5 was such a piece of junk that they
| deleted it so nobody could use it any more. It had its fans
| but they were all deluded. It was a demonstrated fact that
| git5 users were less productive than normal g4 users.
| gpm wrote:
| What is/was "git5"? Git the vcs is only about to release
| version 3.0... Googling only reveals some gene that
| happens to be named that...
| jeffbee wrote:
| It was a way to pretend that you were using git when you
| were in fact using piper.
| bugsliker wrote:
| it's an old google internal interface over google's vcs
| piper that let you use git to manage your changes
| skirmish wrote:
| The big problem with it was that you had to specify
| upfront which directories you will be editing, and only
| those were cloned locally. Later if you wanted to add a
| quick debug printout somewhere else, you would spend 20
| minutes tracking more directories and merging / rebasing
| branches. All because git choked on the huge monorepo.
| WolfeReader wrote:
| Easier CLI, deferred conflict resolution, megamerge workflow,
| an "undo" command which is like a gift from the gods.
| gpm wrote:
| 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.
| steveklabnik wrote:
| 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.
| impure wrote:
| Oh so Google is finally releasing their VCS system I hear so much
| about. Well it's Jj not Piper but it looks like Jj will
| eventually replace Piper and if half the things I've heard about
| Piper are true it will be very successful.
| wffurr wrote:
| It's the front end, not the back end that hosts the repository.
| BeetleB wrote:
| jj is independent of Google.
| 0cf8612b2e1e wrote:
| It does require a google CLA.
| metabagel wrote:
| What does "CLA" stand for?
|
| edit: apparently Contributor License Agreement
| stonogo wrote:
| it is literally impossible to contribute to jj without a
| Google account and a signed agreement with Google.
| inamberclad wrote:
| Not really on topic, but I think it's funny that most MMA style
| gyms always offer Jiu Jitsu and Muay Thai as two classes, right
| after each other. Of the two, Jiu Jitsu seems to generally be the
| more popular one.
| aidenn0 wrote:
| Muay Thai is murder on the joints. BJJ, with its focus on
| ground-work is much easier on my nearly 50-year-old joint.s
| dakiol wrote:
| 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
| affected, and jumping easily to such versions).
|
| Git conflicts are easily solvable as well with a gui (jetbrain
| IDEs) via the cli or via something like Sourcetree. Easily, the
| most used "feature" of git that i use is:
|
| - for a given line of code, see all the files that were touched
| when that line was introduced
|
| But I usually do that via the IDE (because to go through dozens
| of files via cli is a bit of a hassle for me)
|
| So, what am I missing? I know jujutsu is much simple (and
| powerful) than git, but I only have used the "good parts" of git
| and it has never been a bottleneck... but ofc, you don't know
| what you don't know.
| phyrex wrote:
| Not to be a jerk, but 'hundreds of devs and dozens of MR per
| day' is not 'huge repos'. Certain functionality only becomes
| relevant at scale, and what is easy on a repo worth hundreds of
| megabytes doesn't work anymore once you have terabytes of
| source code to deal with.
| ffsm8 wrote:
| > 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?
| CBLT wrote:
| Google's monorepo is in fact terabytes with no binaries. It
| does stretch the definition of source code though - a lot
| of that is configuration files (at worst, text protos)
| which are automatically generated.
| jeffbee wrote:
| git could never, but piper at google is way over that
| figure. Way, way over.
| packetslave wrote:
| Google had 86TB of sourcecode data in Piper way back in
| 2016.
| phyrex wrote:
| Very sure, i work in one
| nh23423fefe wrote:
| I have never understood the claim that git is hard. the docs
| are good and there are plenty of examples online.
|
| feels the same when people say, "jq is hard i use python
| instead" like ok
| CuriouslyC wrote:
| My perspective, git isn't hard, but coordinating git
| workflows in teams with a merge backlog is a real pain in the
| ass.
| bqmjjx0kac wrote:
| 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.
| fernandotakai wrote:
| and i honestly would rather parse json inside ipython and
| then move to a script, than keep invoking `| jq` time and
| time again.
| largbae wrote:
| 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.
| thefifthsetpin wrote:
| 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.
| koiueo wrote:
| There are simply people who've rtfm and people who haven't
| Agingcoder wrote:
| 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.
| thefifthsetpin wrote:
| That explains it for some people, but there's something
| more here.
|
| Hell, I've personally mentored people who struggled with
| git and I could feel their struggle.
|
| I'm not saying that learning git was an insurmountable
| task for them, but their struggle was not something that
| I had to go through.
| LtWorf wrote:
| > after investing significant time and effort into learning
| it.
|
| And the significant time and effort amounts to a total of
| 15 seconds.
| metabagel wrote:
| 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
| gorjusborg wrote:
| The reflog is the failsafe. It is the tool that fixes all
| the scary states, as it keeps a journal of the states of
| each ref in the repo (like branch heads).
|
| You can see where you were and hard reset back, no matter
| what state you are in.
| steveklabnik wrote:
| If you like the reflog, you'll love jj's oplog: it's like
| the reflog, but for _all_ repository state changes.
| litenboll wrote:
| 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.
| Nashooo wrote:
| I mean. How can it be scary when you have git reflog.
| steveklabnik wrote:
| The reflog doesn't capture everything. jj's oplog does.
| Agingcoder wrote:
| 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.
| steveklabnik wrote:
| Even though I never found git hard, I find jj better.
| cosmosgenius wrote:
| one thing which causes problem with git for me is collaborative
| work without using "git server". This usually comes up at
| homelab situation with no access a "git server" or ssh server.
| One thing with jj is i can use existing sharing mechanism like
| dropbox, google drive or if nothing else just copying jj folder
| (granted all of those are bad idea w.r.t vcs but still).
| OkayPhysicist wrote:
| 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.
| metabagel wrote:
| > git init --bare --shared=group
|
| This is a very git command.
| OkayPhysicist wrote:
| It does exactly what it says on the tin:
|
| It calls "git" to "init"ialize a repository, which we
| don't need a working tree for ("bare") and that it's
| going to be "shared" with members of the "group".
| vlovich123 wrote:
| 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.
| steveklabnik wrote:
| > You can copy a .git folder around just fine.
|
| You can do this, but due to file locking, you can corrupt
| the state if it's shared. jj is specifically designed so
| that it won't corrupt the repo in this way: https://jj-
| vcs.github.io/jj/latest/technical/concurrency/
| deepsun wrote:
| 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).
| qudat wrote:
| When you start doing git surgery where there are commit chains
| that need to stay logical is where JJ starts to shine. If you
| are constantly editing previous commits and placing code in
| your working area into those previous commits and rebasing
| original/main.
|
| I also really like that every change is automatically
| committed. It's a great mental model once you get used to it.
| elAhmo wrote:
| 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.
| kubanczyk wrote:
| > So, what am I missing?
|
| Here: git rebase is slightly broken in conflict handling. It
| can be made simpler to understand with jj.
| kyrra wrote:
| 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 is a big
| productivity win for me.
|
| If you want some other points, check out:
| https://fallthrough.transistor.fm/43#t=0h31m5s
|
| Some points from the episode:
|
| * With no separate index vs commit, (everything is just a
| commit), you don't need different commands and flags to deal
| with the different concepts, they are all just marked together.
| In JJ, if you want to stack/stage something, it's just a normal
| commit (no reason to have different concepts here).
|
| * You don't have to name/commit a change at all. Every time you
| run any JJ command (like `jj log`, or `jj status`), it will
| snapshot the changes you have. This means that if you want to
| go work on some other branch, you don't have to go and commit
| your changes (they auto-commit, and you don't have to write a
| description immediately), then update to master branch and
| start working again.
|
| * Or you can just `jj split` (https://jj-
| vcs.github.io/jj/latest/cli-reference/#jj-split), and split a
| working changeset into 2 separate commits.
| shmichael wrote:
| I'm trying to understand, would jj's first class conflicts solve
| the issue of having "stacks" of PRs that can easily be updated at
| any point in the stack? This is one of the features most absent
| from git, but prevalent in Google's tooling as well as Meta's.
| The only good known solution I know is graphite.dev
| gpm wrote:
| Not 100% sure I understand what you're saying, but I think the
| answer is "yes".
|
| You can modify any* commit in `jj` regardless of whether it has
| commits on top of it at any time. Either by another commit into
| it, or by directly checking out the commit and editing the
| source tree. If this creates conflicts with commits on top of
| it `jj` just records those commits as having conflicts/adds
| conflict markers without interrupting the workflow.
|
| * Commits pushed to remotes are marked immutable so you have to
| pass an extra flag to say ignore that and modify them anyways.
| Which you generally wouldn't want to do.
| verdverm wrote:
| 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?
| gpm wrote:
| If I understand you correctly we're imagining you pulled a
| repo with main at commit A. You added commit B on top of A.
| Someone else added commit C on top of A to main on the
| remote, and you're asking what happens?
|
| Nothing until you pull and rebase B on top of C (two
| distinct steps). Once B is on top of C, when B is checked
| out there will be conflict markers in the source tree that
| will presumably break your build until you resolve the
| conflict (unless the conflict is in README or something).
|
| My CI workflow has always been on top of a git based forge.
| As far as the forge is concerned jj _is_ git and absolutely
| nothing changes with regards to that.
| eddd-ddde wrote:
| What you are talking about is solved by jjs auto rebase
| behaviour.
|
| If I amend a commit, all children are rebased automatically.
| sfink wrote:
| This is only absent from git because you said "easily". ;-) git
| can certainly handle doing this, it has more than enough
| functionality for it. But you're kind of fighting against the
| grain to do it.
|
| Yes, jj very much supports this workflow. It's not a single
| feature, though:
|
| - `jj absorb` automatically guesses what patches in your stack
| your changes should go to and puts them there, leaving
| uncertain ones behind. Combine this with `jj undo`, and you can
| first try an absorb and then immediately undo it if it gets it
| wrong. - `jj squash --interactive --into X` (aka `jj squash -i
| -t X`) is the more controlled option, where you can select the
| specific files/hunks/lines to amend X with. The auto-rebasing
| then adjusts the rest of the stack to match. If it creates
| conflicts, you can either undo, fix them now, or fix them
| later. - if you want to experiment with reordering your stack
| (or more generally, reorganizing your DAG), you can do so
| without it making a bigger mess than is absolutely necessary.
| That's not just because of undo. If you try to rebase a patch
| too early and it produces tons of conflicts, you can rebase it
| back and the conflicts will be gone (assuming you didn't have
| some in the first place, but if you did you'll be back to the
| same ones). You can try different places within the stack and
| see what'll work best. - As an expansion of the above, you can
| also split off pieces of one diff and insert it or squash it
| anywhere in the stack (eg `jj split --revision X --insert-after
| Y` aka `jj split -r X -A Y`, or `jj squash --interactive --from
| X --into Y` aka `jj squash -i -f X -t Y`). You don't need to be
| "at" X to rip off pieces and put them elsewhere, you can do it
| anytime.
|
| In summary, the full answer is "hell yeah!"
|
| Note that this doesn't magically eliminate all problems that
| arise from collaboration. You can't push your stack somewhere
| and have other people start working off of it and modifying it
| while modifying it yourself locally. Or rather, you can, but
| you'll end up with a mess. Perhaps much less of a mess than eg
| git, because jj tracks evolving changes and not just commits
| and so you might be able to have _some_ idea of what 's going
| on once you've pulled the conflicting mutations back into your
| local repo. But generally speaking, you still have to be
| disciplined about changing anything that other people can see
| and possibly depend upon. (jj can help by automatically making
| such things immutable once you've made them visible to others,
| but that too can be a bit confusing and require setup specific
| to your situation.) This comes up a lot in code review, and
| there are solutions that handle parts of the problem with
| varying degrees of success, but I've already rambled quite a
| bit.
| thibran wrote:
| jj is so good, finally a tool to replace Git.
|
| SVN -> Git -> jj
| WolfeReader wrote:
| That's an excellent description.
|
| I still remember feeling like a badass using Git-SVN on my SVN-
| based team, and being the only guy who could actually correct
| bad merges and restore lost data without having to plead to our
| SVN admin.
|
| And now I'm feeling like a badass using jj on my Git-based team
| :)
| verdverm wrote:
| No LFS, submodules, hooks, or new tags means jj has some ways
| to go before it is a viable replacement for many organizations
|
| https://jj-vcs.github.io/jj/latest/git-compatibility/
| aidenn0 wrote:
| 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.
| steveklabnik wrote:
| 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.
| verdverm wrote:
| Sounds like I still need git for much of this, so jj and
| the things it does is and additional thing to manage. I've
| been told intermixing them is not a good idea
| acoustics wrote:
| 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, then ping-pong between writing new
| code on top of the change and making reviewer-requested edits
| further down the stack.
___________________________________________________________________
(page generated 2025-10-30 23:00 UTC)