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.
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.
* 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.
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.
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.
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.
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.
The reflog doesn't capture everything. jj's oplog does.
An example of something that the reflog isn't going to capture is a git reset --hard losing your unstaged changes, whereas the equivalent flow and commands in jj would allow you to get those contents back.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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".
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.
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.
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.
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.
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.
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 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 :)
Which is fair as is not expecting everyone to be able to deliver a barnstorming talk. At least not without training.
I'd also flag that the audio is not good which isn't your fault. The trend towards conferences just pointing a camera at a lectern and throwing the footage on YouTube is unfortunate especially when it replaces circulating the slides as opposed to augmenting them. As a form of archive for attendees to review it works but not as a distribution channel.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
A is the remote, B is a coworkers commit, C is mine (iiuc jj uses stacked commits instead of branches)
Let's remove the merge conflict and keep the commits in alphabetical order
B pushes a breaking change, I push a commit to C without knowing.
Are my builds and PRs now at the mercy of changes and events outside of my control?
(my hunch is that there are a bunch of confusing situations in jj like git, and that being different enough will cause user churn and people will stick with the tool they already understand the quirks of)
You're both working on the same branch on the remote? It will refuse to push unless you do `jj git push --force` at which point it will overwrite your coworkers work with yours. This is regardless of conflicts, like with git you have to pull the remote work locally, rebase on it, and then push it.
> iiuc jj uses stacked commits instead of branches
Locally jj doesn't really use branches, you can just create a commit on top of any other commit without creating a branch. It does represent branches (it calls them "bookmarks" for whatever reason) and pushing is pushing a bookmark to a git-branch on the remote.
> Are my builds and PRs now at the mercy of changes and events outside of my control?
I don't believe there's any circumstance where your work is silently rebased on top of other work, or anything else that fits this description.
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.
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.
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.
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.
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 :)
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.
sure, but there are projects that use them already. If jj wants to replace git, it needs to work with people's existing projects without significant changes (ideally none at all)
Changing git hosts happens less frequently than changing clouds, which is infrequent. Changing VCS tools is even less frequent than either of those
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
At the same time, not everyone requires those features. All I mean to say is, the degree of support is varied out of the things mentioned, not just "no support for any of them."
The docs say "no" to support for all of those except tags, which is "partial" because jj can check it ou, but not create them, which hopefully is clear in my comment that "new tags" is still a "no"
I'm going to take the docs for what they say about support over an HN comment
You can trivially run `git tag` and create one, or in your forge and then pull it down. Creating one is not directly supported directly in jj's cli, but if you create a tag, it's in the repo just fine.
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.
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
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.
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.
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).
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.
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.
The full JJ Con playlist is: https://www.youtube.com/playlist?list=PLOU2XLYxmsILM5cRwAK6y...
I find it interesting that the video itself is unlisted.
So do they want people to watch this or not?
It's Google. They are professional foot-shooters when it comes to making their offerings accessible to their audience.
Thanks for this!
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.
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.
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.
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.
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
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 mean. How can it be scary when you have git reflog.
The reflog doesn't capture everything. jj's oplog does.
An example of something that the reflog isn't going to capture is a git reset --hard losing your unstaged changes, whereas the equivalent flow and commands in jj would allow you to get those contents back.
That makes sense
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.
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
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.
If you like the reflog, you'll love jj's oplog: it's like the reflog, but for all repository state changes.
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.
and i honestly would rather parse json inside ipython and then move to a script, than keep invoking `| jq` time and time again.
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.
Even though I never found git hard, I find jj better.
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
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 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.
> after investing significant time and effort into learning it.
And the significant time and effort amounts to a total of 15 seconds.
My perspective, git isn't hard, but coordinating git workflows in teams with a merge backlog is a real pain in the ass.
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).
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.
> 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/
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.
> git init --bare --shared=group
This is a very git command.
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".
> So, what am I missing?
Here: git rebase is slightly broken in conflict handling. It can be made simpler to understand with jj.
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.
> 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.
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.
Very sure, i work in one
git could never, but piper at google is way over that figure. Way, way over.
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.
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.
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.
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 :)
Which is fair as is not expecting everyone to be able to deliver a barnstorming talk. At least not without training.
I'd also flag that the audio is not good which isn't your fault. The trend towards conferences just pointing a camera at a lectern and throwing the footage on YouTube is unfortunate especially when it replaces circulating the slides as opposed to augmenting them. As a form of archive for attendees to review it works but not as a distribution channel.
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.
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 :)
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.
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.
Good advice for presenting a TEDx talk. Bad advice for a technical talk.
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.
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.
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.
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.
I definitely thought we were downstream of pinkmuffinere's critiques about not establishing a reason to be excited about the material. oops.
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.
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.
> 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
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.
I love this. Will review my presentations by this standard in the future haha.
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”
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
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.
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?
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.
A is the remote, B is a coworkers commit, C is mine (iiuc jj uses stacked commits instead of branches)
Let's remove the merge conflict and keep the commits in alphabetical order
B pushes a breaking change, I push a commit to C without knowing.
Are my builds and PRs now at the mercy of changes and events outside of my control?
(my hunch is that there are a bunch of confusing situations in jj like git, and that being different enough will cause user churn and people will stick with the tool they already understand the quirks of)
You're both working on the same branch on the remote? It will refuse to push unless you do `jj git push --force` at which point it will overwrite your coworkers work with yours. This is regardless of conflicts, like with git you have to pull the remote work locally, rebase on it, and then push it.
> iiuc jj uses stacked commits instead of branches
Locally jj doesn't really use branches, you can just create a commit on top of any other commit without creating a branch. It does represent branches (it calls them "bookmarks" for whatever reason) and pushing is pushing a bookmark to a git-branch on the remote.
> Are my builds and PRs now at the mercy of changes and events outside of my control?
I don't believe there's any circumstance where your work is silently rebased on top of other work, or anything else that fits this description.
What you are talking about is solved by jjs auto rebase behaviour.
If I amend a commit, all children are rebased automatically.
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.
>Jujutsu, aka JJ, is an open-source, Git-compatible VCS
Thanks for that context. Why would I want to use it instead of git?
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.
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.
Easier CLI, deferred conflict resolution, megamerge workflow, an "undo" command which is like a gift from the gods.
Because you work for Google, or because you don't want to wait for official git to be rewritten in Rust.
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.
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...
it’s an old google internal interface over google’s vcs piper that let you use git to manage your changes
It was a way to pretend that you were using git when you were in fact using piper.
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.
jj is so good, finally a tool to replace Git.
SVN -> Git -> jj
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 :)
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/
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.
sure, but there are projects that use them already. If jj wants to replace git, it needs to work with people's existing projects without significant changes (ideally none at all)
Changing git hosts happens less frequently than changing clouds, which is infrequent. Changing VCS tools is even less frequent than either of those
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.
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
Sure. Use the tools you like!
At the same time, not everyone requires those features. All I mean to say is, the degree of support is varied out of the things mentioned, not just "no support for any of them."
It's still pre-1.0 software. We'll get there :)
The docs say "no" to support for all of those except tags, which is "partial" because jj can check it ou, but not create them, which hopefully is clear in my comment that "new tags" is still a "no"
I'm going to take the docs for what they say about support over an HN comment
You can trivially run `git tag` and create one, or in your forge and then pull it down. Creating one is not directly supported directly in jj's cli, but if you create a tag, it's in the repo just fine.
FYI: Linux only GA planned for early 2026
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.
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
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
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.
> 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.
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).
> UNIX vendors
Well FreeBSD exists, just look at Netflix
What does "GA" stand for? General availability?
Yes, as in anyone can use it, you don't need special permission.
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.
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
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.
It’s the front end, not the back end that hosts the repository.
jj is independent of Google.
It does require a google CLA.
What does "CLA" stand for?
edit: apparently Contributor License Agreement
it is literally impossible to contribute to jj without a Google account and a signed agreement with Google.