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

11–20 of 66 posts

Re: Jujutsu Megamerges and jj Absorb

#11

Post by stavros »

barakm wrote: post #7
corytheboyd wrote: post #5

Earlier quoted context omitted.

Huh this comment thread may have convinced me to finally try it. I’m comfortable with git, and fixing mistakes in git, but not being able to trivially reverse any and every transaction is annoying.

I hear ya. I've done some crazy things with `git reflog` (which I always pronounce git re-flog instead of ref-log) but it is not fun. There's the usual cognitive shift, and in my case a bit of a best-practice shift I had to go through to get comfortable with `jj` -- specifically, keeping the repo directory pristine (and putting my temp output in a git-ignored dir, or outside the repo) because /everything/ is tracked.…

Are new files tracked by default? If I forget to ignore a bunch of build outputs, will that make my repo huge immediately?

Re: Jujutsu Megamerges and jj Absorb

#12

Post by bjackman »

I am slowly inching towards trying out jj. I think the main issue will be if I find some issue in the git compatibility aspect. I do two kinds of work:

1. Work on smaller projects with simple histories. Git is perfectly satisfactory.

2. Work on huge projects with very complex git histories and weird legacy workflows (primarily Linux kernel).

jj is only interesting for part 2, but then it's only useful if it's easy to bridge into the Git world that everyone else uses.

But this workflow is exactly the kind of thing that seems handy. There's so much stuff that Git can totally _do_ but could just do a lot _better_.

Re: Jujutsu Megamerges and jj Absorb

#13

Post by stouset »

bjackman wrote: post #12

I am slowly inching towards trying out jj. I think the main issue will be if I find some issue in the git compatibility aspect. I do two kinds of work: 1. Work on smaller projects with simple histories. Git is perfectly satisfactory. 2. Work on huge projects with very complex git histories and weird legacy workflows (primarily Linux kernel). jj is only interesting for part 2, but then it's only useful if it's easy to…

Just try it!

I converted 6mo ago after finally pulling together the motivation to give it a shot. My biggest hesitation was in how long I expected to struggle with it before feeling comfortable, followed closely by skepticism about how good the compatibility story actually is.

Both, it turns out, were non issues. It took all of a day to feel perfectly comfortable using it. I spent the rest of the week gradually plugging most of the remaining holes in my workflow. And git compatibility is as advertised. A coworker switched shortly after I did and zero people have noticed or cared.

Though at this point I don’t even bother colocating the .git repo alongside .jj. Meaning I haven’t found a need to fall back to git commands in maybe four or five months.

Re: Jujutsu Megamerges and jj Absorb

#14

Post by masklinn »

stouset wrote: post #13
bjackman wrote: post #12

I am slowly inching towards trying out jj. I think the main issue will be if I find some issue in the git compatibility aspect. I do two kinds of work: 1. Work on smaller projects with simple histories. Git is perfectly satisfactory. 2. Work on huge projects with very complex git histories and weird legacy workflows (primarily Linux kernel). jj is only interesting for part 2, but then it's only useful if it's easy to…

Just try it! I converted 6mo ago after finally pulling together the motivation to give it a shot. My biggest hesitation was in how long I expected to struggle with it before feeling comfortable, followed closely by skepticism about how good the compatibility story actually is. Both, it turns out, were non issues. It took all of a day to feel perfectly comfortable using it. I spent the rest of the week gradually plugg…

How's the tool compatibility when using gg tho? My repo work tends to be split between git and magit, and while I would very much welcome the ability to get rid of git for a better experience, doing so at the cost of magit is an extremely steep hurdle.

Re: Jujutsu Megamerges and jj Absorb

#15

Post by stouset »

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?

To elaborate on the other comments, it is extremely easy to use the op log to undo basically anything.

I was live demoing something and performing some manual repo surgery in order to demonstrate some thing that can happen with git but is nicely solved by jj. In doing the surgery I absolutely fucked everything.

I had never used the undo feature or the op log before. In less than five minutes—during the live demo—I was able to figure out how to reset things back to a known good state. It was stupidly easy.

Re: Jujutsu Megamerges and jj Absorb

#16

Post by stouset »

stavros wrote: post #11
barakm wrote: post #7

Earlier quoted context omitted.

I hear ya. I've done some crazy things with `git reflog` (which I always pronounce git re-flog instead of ref-log) but it is not fun. There's the usual cognitive shift, and in my case a bit of a best-practice shift I had to go through to get comfortable with `jj` -- specifically, keeping the repo directory pristine (and putting my temp output in a git-ignored dir, or outside the repo) because /everything/ is tracked.…

Are new files tracked by default? If I forget to ignore a bunch of build outputs, will that make my repo huge immediately?

There’s a configurable cap on max file size to auto-add, IIRC. It defaults to something “reasonable”.

If you do somehow add a terabyte of small files by accident, it’s still just git under the hood so you can make sure nothing active points at them and GC them.

Re: Jujutsu Megamerges and jj Absorb

#17

Post by masklinn »

setheron wrote: post #9

You've been so welcoming in the jj community. Thank you. I don't understand how absorb works in your example. Why would the commit "z" be affiliated with some random documentation changes you come across and fix in the wip commit. All that I see is it makes it easier to make small refinements to preciously altered lines ? Super excited for jj.... Almost want to find a work opportunity to promote it. Been a refreshing…

> Why would the commit "z" be affiliated with some random documentation changes you come across and fix in the wip commit

It's not? z is the root pseudo-commit.

> All that I see is it makes it easier to make small refinements to preciously altered lines ?

Well yes, the point is to untangle working copies with various unrelated changes (usually fixups) which should really go into older commits.

Re: Jujutsu Megamerges and jj Absorb

#18

Post by Valodim »

So interestingly, many folks I've talked to had a reaction of "so jj is just a frontend to git, big whoop. There are hundreds of them, my favorite is X". That's an understandable reaction.

But jj is more than that, and you couldn't implement it as a git wrapper. I think the core innovation is that rebases are so fast they are essentially free, which opens up amazing potential.

But so far I haven't found a way to really convey the full weight of this without a long explanation, because people are so used to thinking in git, it takes a long time to go beyond "so rebase -i will be faster, then? But it's not slow, is it?"

It's funny, that git is now in the position that subversion was in almost two decades ago: People were so used to svn and felt productive with it, it was hard to convey why free branches and a distributed data model are a gamechanger, and how much svn limited their thinking. But as a git user you had certainty that you were right, and that your tool is superior.

Now, people are so used to git, in an eerily similar way. But ask most git users, "how would you move a specific change from your branch to another?" I have yet to receive a confident answer and workflow to this (they do exist ofc), the common reaction I get is that this isn't something they'd ever need anyways.

I'm curious how this will look in a few years :)

Re: Jujutsu Megamerges and jj Absorb

#19

Post by stavros »

stouset wrote: post #16
stavros wrote: post #11

Earlier quoted context omitted.

Are new files tracked by default? If I forget to ignore a bunch of build outputs, will that make my repo huge immediately?

There’s a configurable cap on max file size to auto-add, IIRC. It defaults to something “reasonable”. If you do somehow add a terabyte of small files by accident, it’s still just git under the hood so you can make sure nothing active points at them and GC them.

I'm thinking of something like node_modules, sounds like I'll need to not forget.

Re: Jujutsu Megamerges and jj Absorb

#20

Post by bayindirh »

Valodim wrote: post #18

So interestingly, many folks I've talked to had a reaction of "so jj is just a frontend to git, big whoop. There are hundreds of them, my favorite is X". That's an understandable reaction. But jj is more than that, and you couldn't implement it as a git wrapper. I think the core innovation is that rebases are so fast they are essentially free, which opens up amazing potential. But so far I haven't found a way to real…

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 use a gazillion branches either, not because I'm afraid of them, but my mental model works like that. Some people squash commits, others rebase, etc. Everybody is different in their ways.

svn to git was a fundamental change and allowed new things to happen. jj on the other hand makes some workflows easier while others take the back seat. So I don't see jj as a git disruptor, but an opinionated alternative tool which uses git data structures as the backend.

Post reply on HN