I had a look at jujutsu the other day. I don't get what the benefit is supposed to be aside from slightly nicer semantics for interactive rebase shenanigans. Plus not having a stash feels weird but that's my personal preference.
Also the official documentation explains everything by way referring back to git, which I feel like is a mistake. I've been working with git since forever so I understood the docs, but I would not feel comfortable to give this to someone who is just getting starting with version control. They'd have to learn both JJ and git at the same time and that's just not great.
Can you tell me, without looking, how, in git, you can split a file from a commit, add it to another commit, then move this new commit to before two commits? Or maybe you're thinking you never even tried to do something like this? Well, that's the benefit. In jj, it's natural to control your change history, in git it's just possible
This is where I would actually switch to a Git GUI client and do things from it. I like seeing visually how my commit tree changes after every command I do. Some of the actions you described, like moving commits up and down the tree require me to press a single button on my keyboard. So, for me, not only doing the work you described is convenient in git due to having a visual, but it's also fast or faster than jj.
However I could see how someone who is not a fan of using GUI software will find jj pleasant to use, and I'm happy to see it growing in popularity. I'd rather see my team mates learn another version control system than making sloppy commits and messy git history.
Have they implemented an equivalent to git pull yet, or do you still have to use jj git fetch followed by jj rebase -d $main_bookmark? It doesn’t look like much progress has been made towards having its own backend and central repository is still git.
jj is still considered experimental and while it might be good for personal projects, but it looks like working with a team and a central repo is a headache. Hope they continue developing though.
Have they implemented an equivalent to git pull yet, or do you still have to use jj git fetch followed by jj rebase -d $main_bookmark?
I'll be honest, I'm not sure about this one.
It doesn’t look like much progress has been made towards having its own backend
The entire presentation is about a google-specific backend, so alternatives do exist and are real. But it's true that there's no jj-native backend. There's not a lot of motivation for such right now, and tons of other work to do. The vast majority of open source users are going to be using a git backend anyway.
it looks like working with a team and a central repo is a headache
It hasn't been, in my experience or many others. But of course, your mileage may vary :)
Sure, someday that would make sense. For now, since something like 95% of the open source world uses git, you are likely to need to use git to interact with others.
In a world where jj gains sufficient mindshare, then there's more reason to implement something. But in terms of where to focus limited time, there are more effective places to do work.
the thing you’re trying to replace
A key part of jj is that because it is backend agnostic, it doesn't actually need to replace git, or anything else. Like "eliminate git" is not a goal of the jj project.
What is the goal of jujutsu then? It’s a VCS, git is a VCS. If you’re saying use jujutsu, then you’re either saying use both, or use jujutsu instead of git. If it’s the former then why would I want to use 2 VCSs? If it’s the latter, then how is replacing git not the project’s goal?
Why not take the time you would spend learning a new VCS, and use it to actually learn git?
You could say that jj is actually doing what Linus wanted for Git, to make the UI and workflow that works well for them. The plumbing (Git) and the porcelain (jj).
You could say that, but you’d be wrong. Linus made Git the way he wanted to work the way he wanted. If he wanted Git to work differently, he would have made it differently.
Linus doesn’t even use most of the features of Git, he said that he only really uses 5 commands. All the extra stuff was added by contributors afterwards.
Go watch interviews with Linus talking about Git. He wasn’t trying to build “the best VCS”, he built the best VCS for himself and the kernel team.
He’s actually not interested in VCS and that’s why he doesn’t contribute to Git or even read the newsletter anymore. He definitely isn’t using jj, and if jj was what he wanted for Git then he’d be using jj.
If your bookmark can be "fast forwarded" it will do just that yes. In case it can, you'll get two branches (in the graph sense, not in the github sense) and you can do whatever you want
git checkout just the one split file from the old commit
git cherry-pick the other commit I wanted on top
Finally, git rebase the old commit on top of the stack
"Editing" commits just creates new commits anyway, so I feel like building the branch afresh is a fairly natural way to solve the problem. Git is one of the least user-friendly modern distributed VCSes, but you should be able to solve any problem with just a few primitives.
Like I said, anything is possible in git, the trick is how hard it is. All of checkout, cherry pick and rebase are full all arcane options and can lose your work. In jj this kind of operation is extremely basic
You have to go out of your way to lose (committed) work if you get one of those commands wrong. Git doesn't immediately delete old commits, even if there are no references. You can always undo a failed checkout, cherry pick or rebase by resetting the branch to an earlier commit from the branch's reflog
All of checkout, cherry pick and rebase are full all arcane options and can lose your work.
jj aside, that's just not materially true. The challenge you proposed is categorically easy, even with the rebase solution which takes more individual steps than the new-branch solution. It's just... not hard. But we are not born with this knowledge, it's not built into our DNA. Version control is treated like some barely tolerated necessary evil that can demand no resources, certainly no mental ones, but in reality it's one of the most important tools we interact with and one of the only tools consistently represented in all branches of software development.
Then remove all files but the target file from the staged changes
git commit -m "New Commitgit commit -m "Original commit w/o the filegit rebase --continue
I haven't done that exact operation before, but I have moved files out of past commits into later commits and I have reordered commits before. But it does not come up super often. Maybe once a year?
I don't get what the benefit is supposed to be aside from slightly nicer semantics for interactive rebase shenanigans.
Here's what I wrote about this eight days ago, and there's also a lot of other comments from other people: https://news.ycombinator.com/item?id=45673808
To me, the short summary is: it's both more powerful than git, and simpler, at the same time. This is because the internals are better factored. Everything really clicks together in a way that I thought git did until I used jj.
That said: if you like your tools, you should use the ones you like. If jj's not your cup of tea, that's fine. It's also still pre-1.0, so there's lots more work to do.
I would guess the benefit will be mostly internal to Google, where most new hires won’t come in with Perforce experience. Instead of teaching them Piper (which operates like Perforce) they add Jujutsu services which can act like a smart proxy layer between Git CLI and Piper+CitC.
Meta also uses a mercurial fork (sapling), and what they found internally is that even coming from git, people end up preferring it a lot of the time. Especially around things like anonymous branches; the vast, vast majority of users ended up no longer naming their branches after a couple of weeks of usage.
Anonymous branches make sense for trunk-based development, but I don't thing this is a significant difference between the systems.
I think git workflow in general still makes more sense to me, since splitting (Fig or jj) feels much more convoluted than beginning with the small commits in the first place (git).
Nothing really forces you to do the splitting, I personally just commit early and often, as I did in git, and then squash together rather than split things, but if you find git more intuitive, you should stick to git, it's all good :)
Google has had Fig for several years now, which is a Mercurial frontend to Piper. New hires are trained on Fig and most probably never learn how to interact with Piper directly.
Fig/Mercurial is very similar to Git, so it should be a lot easier for people with Git experience to learn. Though Mercurial is in general easier to use and more foolproof than Git.
I used Fig when it was new and enjoyed it over the Piper workflows, especially the ability to chain CLs. But I think the talk mentions this is an eventual replacement for Fig. I think it’s the same situation. Who comes in with Mercurial experience? Meta uses it. Anyone else? Even though I think Mercurial is better, Git won the most users so it probably makes the most sense to try to cater to the predominant tech.
If you can seamlessly switch between changes you don't need a stash. JJ has entirely obviated both the stash and workspaces for me and I previously used both quite extensively.
It's just a personal preferences of metaphors. Putting work literally aside from the branches I'm working on fits well with how I'm using stashes most times.
Also I abuse the stash a lot to quickly cycle between an in-progress change and the last commit if I'm unsure about the change for some reason and want to compare the changed to the prior version w/o having that prior version conveniently deployed on a test stage.
Putting work literally aside from the branches I'm working on fits well with how I'm using stashes most times.
For sure, and this is something I do a lot too, it's just that it's simpler with jj because it's not a special command: it's just another commit, like any other.
I guess that would be prev / next in jj.
I do the "stash a lot" sort of workflow and I very rarely use prev/next.
The equivalent of "stash my current changes" is just jj new @-, that is, "create a new change from my parent." Now you're working on a sibling. If you want to leave it purely anonymous like a stash, you're done, if you want to give it a short description to remember what's in it, you jj describe before you new.
Oh, I am aware. It's just that outside of the scenario where I go back and forth between commit and work-in-progress, I usually prefer that my change-set is floating aside from the branch structure. Because usually when I stash something longer term (>30 minutes) I do it precisely because I haven't made up my mind what to do with those changes yet. Or it's a changeset I want to be able to temporarily put on top of more than one branch if needed. I know that I can do all that in jj with the methods you described, but I just prefer the git mental model. Plus I don't have to juggle any commit IDs and fiddle with the branch histories. :)
Cool just making sure to everyone else it’s clear that jj can do this.
Jj’s model makes it easier for me, I only could ever manage one level of stash with git but can do it much more and more easily with jj. But you should use what works for you :)
I don't get what the benefit is supposed to be...
This is a common worry everywhere jj show, and most of the time from hard-core git users that, somehow, manage to "like" git despite being an obtuse tool. I concur that (for necessity!) being tied to git make a bit harder to see the appeal...
What is the benefit? JJ is sane in both UX AND semantics.
What git allow with myriad of poorly porcelains jj do in so few that is a shock, is rare to see a tool that is truly more powerful than the replacement but far simpler at the end.
In the end, whatever you are the kind of person that, somehow, think that learn the internals of git is what make git works, or more normally, the myriad of people that have the misfortune of use it, NOT MATTER because jj make for both the same workflow, give the same powers and in practice, will translate to only use no more than 10 commands for life.
What are the drawbacks?
In special for seasoned git users, it need to use it for some time to see how much sane is it
There is not integration in the major forges, that is the reasons jj need to refer to git all the time. But if you use it nobody else will know, the effects will be transparent for the world
Diff need config to make it work with some tools. In general, external tools could have poor understanding of a jj colocated repo, so this is the actual major thing
People write git tooling and wrappers since it went big. None of the stuff endured.
I can see that git isn't ideal for every workflow, but people also overthink their workflows and version control. For a small skilled coder teams, rebasing is pretty solid. For large companies, well they will create weird tooling and policies anyway. They solve their problems, they should keep it to themselves.
If you want to be able to, post-hoc, group and prettify or otherwise change your commits -- it make that much easier.
It, basically, loosens the coupling between commits/organization and actual changes.
If you think of git as changes to code with descriptions added, you can think of jj as mutable descriptions that also have code changes.
Obviously there's more nuance, but that's basically the gist.
I can see why someone would want it. But I found it basically ... making it easier to do work that I didn't really value ... which ended up being more work in the end despite the "easier" part.
I think there's value in it, but it doesn't address the opacity of the git model -- and instead adds additional distance from it. Feels like 1/2 of a good thing, but wasn't for me.
(But I can also see the interest and how it serves the needs of larger and more complicated teams more perhaps(?))
But I found it basically ... making it easier to do work that I didn't really value ... which ended up being more work in the end despite the "easier" part.
When I did my little test repo, I actually had to look up to undo stuff properly because I did some npm install commands before I added a .gitignore file. I am also very used to making a whole bunch of changes for a feature and then cutting commits from that big pie. From my brief experimentation and the information in the docs that is backwards from what you're supposed to do with jujutsu.
Partially alleviated by the ease of modifying history of course. But still weird in a way that I'm not sure I can get used to after half a lifetime of git.
You can easily "cut up" commits after working on the entire feature without any commits. That's a first-class workflow in jj. You just create a new changeset (jj new), with or without a description, then use jj split -i to interactively select files or even chunks to be split into a new changeset before your current one. In this way, you can keep splitting your final state into as many commits as you want.
You can also use jj squash to push any edits/files in your current changeset to a previous one, which is another way you could do the same thing.
I understand how overwhelming working at a company like Google can feel. It moves incredibly fast and has such a vast ecosystem.
When I first joined, even though I was excited, the sheer pace and complexity of their operations were intimidating. It definitely requires adapting your approach to jujutsu - finding ways to implement changes effectively while also respecting Google's unique culture and processes.
From my experience, one of the most valuable things you can do is to build strong relationships with people who are closer to execution or have a different perspective than the typical strategic thinker. They often have brilliant insights that strategy documents miss.
It also helped me focus on mastering their internal tools rather than trying to "work around" them. Understanding how Gmail or Hangouts worked was essential for effective communication.
Don't be afraid to fail at implementing your ideas, but do try to understand the feedback loops.
I'm so excited for this to become more widespread. Piper was one of the tools I missed most after leaving Google. The fact that it lets you add wrappers for whichever command/workflow structure you were most comfortable with (e.g. git or mercurial) was so nice. The mercurial workflow became so comfortable to use and going back to Git was a tad painful.
Piper merges were fantastic and handled pending CLs stacked on each other so much more cleanly than other workflows I've seen in Git production repos.
lotgd-archivist@reddit
I had a look at jujutsu the other day. I don't get what the benefit is supposed to be aside from slightly nicer semantics for interactive rebase shenanigans. Plus not having a stash feels weird but that's my personal preference.
Also the official documentation explains everything by way referring back to git, which I feel like is a mistake. I've been working with git since forever so I understood the docs, but I would not feel comfortable to give this to someone who is just getting starting with version control. They'd have to learn both JJ and git at the same time and that's just not great.
teerre@reddit
Can you tell me, without looking, how, in git, you can split a file from a commit, add it to another commit, then move this new commit to before two commits? Or maybe you're thinking you never even tried to do something like this? Well, that's the benefit. In jj, it's natural to control your change history, in git it's just possible
andreicodes@reddit
This is where I would actually switch to a Git GUI client and do things from it. I like seeing visually how my commit tree changes after every command I do. Some of the actions you described, like moving commits up and down the tree require me to press a single button on my keyboard. So, for me, not only doing the work you described is convenient in git due to having a visual, but it's also fast or faster than
jj.However I could see how someone who is not a fan of using GUI software will find
jjpleasant to use, and I'm happy to see it growing in popularity. I'd rather see my team mates learn another version control system than making sloppy commits and messy git history.teerre@reddit
Yeah, that's a classic git issue. It's so complicated that people build whole new applications on top of it
And yet, even then it comes short. By far the best vcs ux I ever experienced is jjui. If we're going to compare UIs, it's even worse for git
arpan3t@reddit
Have they implemented an equivalent to git pull yet, or do you still have to use
jj git fetchfollowed byjj rebase -d $main_bookmark? It doesn’t look like much progress has been made towards having its own backend and central repository is still git.jj is still considered experimental and while it might be good for personal projects, but it looks like working with a team and a central repo is a headache. Hope they continue developing though.
steveklabnik1@reddit (OP)
I'll be honest, I'm not sure about this one.
The entire presentation is about a google-specific backend, so alternatives do exist and are real. But it's true that there's no jj-native backend. There's not a lot of motivation for such right now, and tons of other work to do. The vast majority of open source users are going to be using a git backend anyway.
It hasn't been, in my experience or many others. But of course, your mileage may vary :)
arpan3t@reddit
I would think the motivation to not be reliant on the thing you’re trying to replace would be sufficient.
If it works for you and you’re happy then that’s great!
steveklabnik1@reddit (OP)
Sure, someday that would make sense. For now, since something like 95% of the open source world uses git, you are likely to need to use git to interact with others.
In a world where jj gains sufficient mindshare, then there's more reason to implement something. But in terms of where to focus limited time, there are more effective places to do work.
A key part of jj is that because it is backend agnostic, it doesn't actually need to replace git, or anything else. Like "eliminate git" is not a goal of the jj project.
arpan3t@reddit
What is the goal of jujutsu then? It’s a VCS, git is a VCS. If you’re saying use jujutsu, then you’re either saying use both, or use jujutsu instead of git. If it’s the former then why would I want to use 2 VCSs? If it’s the latter, then how is replacing git not the project’s goal?
Why not take the time you would spend learning a new VCS, and use it to actually learn git?
double-you@reddit
You could say that jj is actually doing what Linus wanted for Git, to make the UI and workflow that works well for them. The plumbing (Git) and the porcelain (jj).
arpan3t@reddit
You could say that, but you’d be wrong. Linus made Git the way he wanted to work the way he wanted. If he wanted Git to work differently, he would have made it differently.
Linus doesn’t even use most of the features of Git, he said that he only really uses 5 commands. All the extra stuff was added by contributors afterwards.
double-you@reddit
Yes and no, Linus added the interface he wanted and could use but also understood that it is not the best and left that to other people.
arpan3t@reddit
Go watch interviews with Linus talking about Git. He wasn’t trying to build “the best VCS”, he built the best VCS for himself and the kernel team.
He’s actually not interested in VCS and that’s why he doesn’t contribute to Git or even read the newsletter anymore. He definitely isn’t using jj, and if jj was what he wanted for Git then he’d be using jj.
steveklabnik1@reddit (OP)
The goal of jj is to be a good VCS.
That doesn’t mean that any other VCS has to cease to exist.
Jj being able to work on a git repo doesn’t even mean git has to exist. It just means that it can interoperate well.
Version control systems are a means of collaboration, and so playing nicely with others is a virtue, not a drawback.
teerre@reddit
If your bookmark can be "fast forwarded" it will do just that yes. In case it can, you'll get two branches (in the graph sense, not in the github sense) and you can do whatever you want
lord_braleigh@reddit
I would generally:
git checkoutjust the one split file from the old commitgit cherry-pickthe other commit I wanted on topgit rebasethe old commit on top of the stack"Editing" commits just creates new commits anyway, so I feel like building the branch afresh is a fairly natural way to solve the problem. Git is one of the least user-friendly modern distributed VCSes, but you should be able to solve any problem with just a few primitives.
teerre@reddit
Like I said, anything is possible in git, the trick is how hard it is. All of checkout, cherry pick and rebase are full all arcane options and can lose your work. In jj this kind of operation is extremely basic
phlipped@reddit
You have to go out of your way to lose (committed) work if you get one of those commands wrong. Git doesn't immediately delete old commits, even if there are no references. You can always undo a failed checkout, cherry pick or rebase by resetting the branch to an earlier commit from the branch's reflog
steveklabnik1@reddit (OP)
jj also has the oplog, which is like the reflog but for all repository state.
Imatros@reddit
How would you do it in jj?
doener@reddit
jj split --from <src-commit> -B @-- <path>(or use-ifor an interactive picker instead of a path)Don't pin me down on the number of minus signs, I'd usually use a commit/change id there.
ForeverAlot@reddit
jj aside, that's just not materially true. The challenge you proposed is categorically easy, even with the rebase solution which takes more individual steps than the new-branch solution. It's just... not hard. But we are not born with this knowledge, it's not built into our DNA. Version control is treated like some barely tolerated necessary evil that can demand no resources, certainly no mental ones, but in reality it's one of the most important tools we interact with and one of the only tools consistently represented in all branches of software development.
ozyx7@reddit
That's pretty easy to do with
git revisetoo.git revise -i, mark the desired commit as "cut" to split it into two parts.git revise -iagain, reorder the commits to move the part you want.lotgd-archivist@reddit
Without looking it up or trying it out:
git rebase -iediton the target commitThen remove all files but the target file from the staged changes
git commit -m "New Commitgit commit -m "Original commit w/o the filegit rebase --continueI haven't done that exact operation before, but I have moved files out of past commits into later commits and I have reordered commits before. But it does not come up super often. Maybe once a year?
steveklabnik1@reddit (OP)
Here's what I wrote about this eight days ago, and there's also a lot of other comments from other people: https://news.ycombinator.com/item?id=45673808
To me, the short summary is: it's both more powerful than git, and simpler, at the same time. This is because the internals are better factored. Everything really clicks together in a way that I thought git did until I used jj.
That said: if you like your tools, you should use the ones you like. If jj's not your cup of tea, that's fine. It's also still pre-1.0, so there's lots more work to do.
Flashy_Current9455@reddit
Your patience in answering this question again and again is remarkable
steveklabnik1@reddit (OP)
Thanks.
SadEngineer6984@reddit
I would guess the benefit will be mostly internal to Google, where most new hires won’t come in with Perforce experience. Instead of teaching them Piper (which operates like Perforce) they add Jujutsu services which can act like a smart proxy layer between Git CLI and Piper+CitC.
steveklabnik1@reddit (OP)
Meta also uses a mercurial fork (sapling), and what they found internally is that even coming from git, people end up preferring it a lot of the time. Especially around things like anonymous branches; the vast, vast majority of users ended up no longer naming their branches after a couple of weeks of usage.
sviperll@reddit
Anonymous branches make sense for trunk-based development, but I don't thing this is a significant difference between the systems.
I think git workflow in general still makes more sense to me, since splitting (Fig or jj) feels much more convoluted than beginning with the small commits in the first place (git).
steveklabnik1@reddit (OP)
Nothing really forces you to do the splitting, I personally just commit early and often, as I did in git, and then squash together rather than split things, but if you find git more intuitive, you should stick to git, it's all good :)
Kered13@reddit
Google has had Fig for several years now, which is a Mercurial frontend to Piper. New hires are trained on Fig and most probably never learn how to interact with Piper directly.
Fig/Mercurial is very similar to Git, so it should be a lot easier for people with Git experience to learn. Though Mercurial is in general easier to use and more foolproof than Git.
SadEngineer6984@reddit
I used Fig when it was new and enjoyed it over the Piper workflows, especially the ability to chain CLs. But I think the talk mentions this is an eventual replacement for Fig. I think it’s the same situation. Who comes in with Mercurial experience? Meta uses it. Anyone else? Even though I think Mercurial is better, Git won the most users so it probably makes the most sense to try to cater to the predominant tech.
shahms@reddit
If you can seamlessly switch between changes you don't need a stash. JJ has entirely obviated both the stash and workspaces for me and I previously used both quite extensively.
lotgd-archivist@reddit
It's just a personal preferences of metaphors. Putting work literally aside from the branches I'm working on fits well with how I'm using stashes most times.
Also I abuse the stash a lot to quickly cycle between an in-progress change and the last commit if I'm unsure about the change for some reason and want to compare the changed to the prior version w/o having that prior version conveniently deployed on a test stage.
steveklabnik1@reddit (OP)
For sure, and this is something I do a lot too, it's just that it's simpler with jj because it's not a special command: it's just another commit, like any other.
I do the "stash a lot" sort of workflow and I very rarely use prev/next.
The equivalent of "stash my current changes" is just
jj new @-, that is, "create a new change from my parent." Now you're working on a sibling. If you want to leave it purely anonymous like a stash, you're done, if you want to give it a short description to remember what's in it, youjj describebefore younew.lotgd-archivist@reddit
Oh, I am aware. It's just that outside of the scenario where I go back and forth between commit and work-in-progress, I usually prefer that my change-set is floating aside from the branch structure. Because usually when I stash something longer term (>30 minutes) I do it precisely because I haven't made up my mind what to do with those changes yet. Or it's a changeset I want to be able to temporarily put on top of more than one branch if needed. I know that I can do all that in jj with the methods you described, but I just prefer the git mental model. Plus I don't have to juggle any commit IDs and fiddle with the branch histories. :)
steveklabnik1@reddit (OP)
Cool just making sure to everyone else it’s clear that jj can do this.
Jj’s model makes it easier for me, I only could ever manage one level of stash with git but can do it much more and more easily with jj. But you should use what works for you :)
mamcx@reddit
What is the benefit? JJ is sane in both UX AND semantics.
What git allow with myriad of poorly porcelains jj do in so few that is a shock, is rare to see a tool that is truly more powerful than the replacement but far simpler at the end.
In the end, whatever you are the kind of person that, somehow, think that learn the internals of git is what make git works, or more normally, the myriad of people that have the misfortune of use it, NOT MATTER because jj make for both the same workflow, give the same powers and in practice, will translate to only use no more than 10 commands for life.
What are the drawbacks?
Zomgnerfenigma@reddit
People write git tooling and wrappers since it went big. None of the stuff endured.
I can see that git isn't ideal for every workflow, but people also overthink their workflows and version control. For a small skilled coder teams, rebasing is pretty solid. For large companies, well they will create weird tooling and policies anyway. They solve their problems, they should keep it to themselves.
MassiveInteraction23@reddit
If you want to be able to, post-hoc, group and prettify or otherwise change your commits -- it make that much easier.
It, basically, loosens the coupling between commits/organization and actual changes.
If you think of git as changes to code with descriptions added, you can think of jj as mutable descriptions that also have code changes.
Obviously there's more nuance, but that's basically the gist.
I can see why someone would want it. But I found it basically ... making it easier to do work that I didn't really value ... which ended up being more work in the end despite the "easier" part.
I think there's value in it, but it doesn't address the opacity of the git model -- and instead adds additional distance from it. Feels like 1/2 of a good thing, but wasn't for me.
(But I can also see the interest and how it serves the needs of larger and more complicated teams more perhaps(?))
lotgd-archivist@reddit
When I did my little test repo, I actually had to look up to undo stuff properly because I did some
npm installcommands before I added a.gitignorefile. I am also very used to making a whole bunch of changes for a feature and then cutting commits from that big pie. From my brief experimentation and the information in the docs that is backwards from what you're supposed to do with jujutsu.Partially alleviated by the ease of modifying history of course. But still weird in a way that I'm not sure I can get used to after half a lifetime of git.
FirstBabyChancellor@reddit
You can easily "cut up" commits after working on the entire feature without any commits. That's a first-class workflow in jj. You just create a new changeset (jj new), with or without a description, then use jj split -i to interactively select files or even chunks to be split into a new changeset before your current one. In this way, you can keep splitting your final state into as many commits as you want.
You can also use jj squash to push any edits/files in your current changeset to a previous one, which is another way you could do the same thing.
luisvalerio@reddit
in case it helps anyone who is in a rush or wants to recap, here's an interactive summary of the video: https://app.sharpana.ai/summary/ff72bdd7-e909-49de-97eb-92e4de5e5a3a?m=i&s=ydaZS29Y
Small note: video views from there also count favorably towards the author, since that tool is using the official embedded youtube player
sob727@reddit
Jujutsu? I'm going to learn Jujutsu?
sviperll@reddit
Does jj allow you to show merge commits?
Zeitsplice@reddit
AIUI, merges and rebases have their own temp commits that can then be mashed into main commits when they're ready to push.
sviperll@reddit
I mean is it possible to see how conflicts were resolved, like in git combined diff?
steveklabnik1@reddit (OP)
I believe that that is the case, yes. That is, a merge commit that resolves conflicts has the resolution as its diff.
Thin-Yard471@reddit
I understand how overwhelming working at a company like Google can feel. It moves incredibly fast and has such a vast ecosystem.
When I first joined, even though I was excited, the sheer pace and complexity of their operations were intimidating. It definitely requires adapting your approach to jujutsu - finding ways to implement changes effectively while also respecting Google's unique culture and processes.
From my experience, one of the most valuable things you can do is to build strong relationships with people who are closer to execution or have a different perspective than the typical strategic thinker. They often have brilliant insights that strategy documents miss.
It also helped me focus on mastering their internal tools rather than trying to "work around" them. Understanding how Gmail or Hangouts worked was essential for effective communication.
Don't be afraid to fail at implementing your ideas, but do try to understand the feedback loops.
aqjo@reddit
Kris recently spoke with the creator of jujutsu. https://youtu.be/ulJ_Pw8qqsE?si=ZQGD3u-Y65NOQiFD
Confused_CS_Dude@reddit
I'm so excited for this to become more widespread. Piper was one of the tools I missed most after leaving Google. The fact that it lets you add wrappers for whichever command/workflow structure you were most comfortable with (e.g. git or mercurial) was so nice. The mercurial workflow became so comfortable to use and going back to Git was a tad painful.
Piper merges were fantastic and handled pending CLs stacked on each other so much more cleanly than other workflows I've seen in Git production repos.