Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jujutsu Megamerges and jj Absorb

v5.chriskrycho.com

Post reply on HN
Print view View original

61–66 of 66 posts

Re: Jujutsu Megamerges and jj Absorb

#61

Post by evgpbfhnr »

Macha wrote: post #29
evgpbfhnr wrote: post #26

How does jj handle very large git repos, e.g. this linux clone with a mix&mash of quite a few upstreams with a 6GB big .git dir? (I agree I probably shouldn't focus on that first, and could just try jj first on smaller rpos... But git is already slow enough in there that it's an honest question, I don't need to keep using git there as long as I can keep pulling from stable kernels git trees for regular merges)

It works fine on nixpkgs, which is by some measures larger than the linux git repo. jj git clone/fetch/push are using the corresponding git commands under the hood so they won't improve on git performance but also it doesn't have much overheard of its own. If you're using the -T revset syntax, you can specify a revset that requires looking at every commit, which is slow, but that's equivalent to asking for `git log -…

Thanks! My nixpkgs clone is 5.2GB so it's not too far indeed! :)

I think the nixpkgs workflow is much less prone to rebase/merges (some cherry-picks to stable branches I don't do much), but it's a very good data point, thank you. I guess I'll give it a try over christmas break..

Re: Jujutsu Megamerges and jj Absorb

#62

Post by stouset »

steveklabnik wrote: post #55
Izkata wrote: post #51

Earlier quoted context omitted.

> Do you ever want to go back and edit a previous unpublished commit? Yes fixups exist, but that’s a band aid over the fact that editing a previous one is annoying and hard. Also unnecessary, "git rebase -i" has an "edit" command that pauses the rebase at that commit to let you do whatever.

What jj does is not require you to pause. It’s fine with leaving stuff in a conflicted state, letting you do whatever you want as a next step. That may be resolving the rebase, but maybe you didn’t realize you were gonna have a conflict and want to get something else done real quickly. In-memory, always succeeding rebases are just really nice.

And also you can just… edit a commit. It’s not some special side effect of a certain flag to a different command. You can just say “gosh I really wish I’d made some changes here” and either move changes in, or just jump in and live-edit it directly.

It’s really a completely different way of thinking, but shockingly, one that essentially directly maps to what your actual intentions are.

Re: Jujutsu Megamerges and jj Absorb

#63

Post by stouset »

barakm wrote: post #3
xyzsparetimexyz wrote: post #2

This does halfway convince me to try it using jujitsu.. However I think the biggest barrier so far is that I understand how to undo mistakes in git but I don't in jujitsu.. if you accidentally run 'jj squash --into x --keep-emptied' when you meant 'jj squash --into n --keep-emptied', how do you undo that?

Literally `jj undo` There's a whole operation log (`jj op log`), as another sequence of actions, and you can undo them. It gets crazier from there, but I've also been enjoying jujutsu lately and I had to RTFM a good couple of times to get comfortable with it.

Also cool: jujutsu remembers every previous state of all your changes. So you make some edits, run `jj status` (or anything), and keep working.

Two hours later you realize your experiment is a total failure and you wish you had the half-working changes from earlier. You don’t need to have actively commited anything, it’s all in the obsolte log and you can retrieve it.

I want to repeat that last bit. Unlike git, there was no point where you needed to finalize your changes with a commit in order for them to be persisted and archived for later retrieval.

Re: Jujutsu Megamerges and jj Absorb

#64

Post by chriskrycho »

kkfx wrote: post #59

It's a bit a joke, but not too much: the next step will be full integration with editor's undo/redo mechanism, which in the end could be seen as a log-based storage. Because that's the trend I've seen on the (little) new ideas from the VCS world.

If you enable the watchman integration, then you actually get very close to this: your current change’s evolution log and the repo operation log will have every change which was persisted to disk. There are tradeoffs to that, of course, but it’s a very powerful capability—and notice that it’s something that would be a huge pain to cobble together somehow in GitHub which Just Works in Jujutsu. It falls cleanly out of making the working copy a commit.

Re: Jujutsu Megamerges and jj Absorb

#65

Post by bayindirh »

stouset wrote: post #48
bayindirh wrote: post #20

Earlier quoted context omitted.

The difference between git and svn is, svn is very fixed in terms of workflow. On the other hand, git allows many different workflows, and allows people to handle their codebases the way they see fit. Of course, no tool is truly universal, and git frontends and alternatives leverage different parts of the underlying data structures with different trade-offs. I personally never use rebase, and am a merge guy. I don't…

> I personally never use rebase Probably a lot of that is because it is painful. When it becomes a no-op, suddenly a lot of things become easy to do. Do you ever want to go back and edit a previous unpublished commit? Yes fixups exist, but that’s a band aid over the fact that editing a previous one is annoying and hard. Do you ever want to maintain a linear chain of branches? Branch A needs to be merged before Branch…

No, not because it's painful, I just don't need it.

> Do you ever want to go back and edit a previous unpublished commit?

Honestly, no? I plan what I'm going to change, do it, commit it, and if I messed up, I don't hide it, just fix it and write "I messed up X in $HASH. This fixes that".

> Do you ever want to maintain a linear chain of branches?

No, I always keep a single thing moving at one time. If the project is big, I use a branch per feature, if it's a smaller branch, there's a development branch. That's all. I have a habit of designing before touching code, so I always move in well planned moves.

It's not like that because I'm afraid of rebase. It's just how I design/implement software. Yes, it's generally not a group work, but I do what I do, and it works.

> There are a ton of straightforward and useful workflows in git that are just completely impractical.

That's fine. I don't claim otherwise. I just don't do to prefer source code / branch acrobatics. I'd love to share a seven year development tree to show how I work, but unfortunately that repo is not meant to be open, at least for now.

Re: Jujutsu Megamerges and jj Absorb

#66

Post by williamdclt »

stouset wrote: post #46
williamdclt wrote: post #22

Earlier quoted context omitted.

> this isn't something they'd ever need anyways. Oh I do that quite often, either because I didn’t realise I was committing on the wrong branch, or I decided to split my work in two branches, or i need some other unmerited change for my current branch… It’s usually a rebase —onto or cherry-pick, I’d say I agree it’s not simple. jj seems interesting, I’m very comfortable with git but I think its UX is terrible, but ev…

Nobody else needs to convert to jj for you to use it, so there’s no real downside to switching.

The downside part is "it is not an area where I have capacity or willingness to innovate". I'd happily follow, I don't care enough to lead the innovation.
Post reply on HN