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

Jujutsu at Google [video]

youtube.com

Post reply on HN
Print view View original

191–200 of 212 posts

Re: Jujutsu at Google [video]

#191

Post by martinvonz »

1718627440 wrote: post #188
steveklabnik wrote: post #183

Earlier quoted context omitted.

Sure, you could view it as Drobox's problem, but the core of it is that git relies on things that Dropbox doesn't support, while jj does not. And so it's usable more safely in more contexts. I fully agree that this is a niche use-case.

JJ works when an internal file is overwritten to another version, while it does an operation? I thought that's what we are discussing here.

No, it avoids doing that (see the link someone shared above). Git actually also rarely overwrites files. The only case I'm aware of are refs, so I think it could happen that a if you modify a branch on two machines and then sync via Dropbox/rsync, one of those changes could get lost.

Re: Jujutsu at Google [video]

#192

Post by 1718627440 »

martinvonz wrote: post #186
1718627440 wrote: post #184

Earlier quoted context omitted.

> Ah, I see, so you avoid interactive rebase and instead make all changes in the working copy and use `git commit --fixup` and `git rebase -i . I wouldn't say I avoid this, I also run `git rebase -i` several times per day, and I also often use `git commit --fixup` during a rebase. > Makes sense, but doesn't it break down when there are conflicts between the changes you're making in the working copy and the target com…

> I just resolve them? I think I don't understand this question. In order to make changes to commit A when there are conflicting changes in B, I was thinking that you would have to use interactive rebase instead because you can no longer make those changes in the working copy and use `git commit --fixup`, right? And because there will now be conflicts in commit B, you will be in this "interrupted rebase" state where…

> I was thinking that you would have to use interactive rebase instead because you can no longer make those changes in the working copy and use `git commit --fixup`, right? And because there will now be conflicts in commit B, you will be in this "interrupted rebase" state

Yes.

I don't see the drawback honestly. Invoking git rebase, means I want to resolve conflicts now, when I want to do that later, I can just call git rebase later. When you want to work on top of the B with conflicts, the code wouldn't even compile, so I expect JJ, to just give you the code before the squash, right? How is this different from in Git?

Re: Jujutsu at Google [video]

#193

Post by 1718627440 »

sfink wrote: post #99
shmichael wrote: post #45

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

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. Com…

> But you're kind of fighting against the grain to do it.

> `jj absorb`

git absorb exists.

Re: Jujutsu at Google [video]

#194

Post by 1718627440 »

martinvonz wrote: post #191
1718627440 wrote: post #188

Earlier quoted context omitted.

JJ works when an internal file is overwritten to another version, while it does an operation? I thought that's what we are discussing here.

No, it avoids doing that (see the link someone shared above). Git actually also rarely overwrites files. The only case I'm aware of are refs, so I think it could happen that a if you modify a branch on two machines and then sync via Dropbox/rsync, one of those changes could get lost.

Ah, you mean to share the repo you are issuing git commands to directly. Yeah I would expect this to cause problems. Surprising to hear that JJ supports this.

This wasn't what I was talking about, I meant that you should create a bare repo and push to it, not that you work directly in a directory in Dropbox.

Re: Jujutsu at Google [video]

#195

Post by skirmish »

shadowgovt wrote: post #73
skirmish wrote: post #70

Earlier quoted context omitted.

> 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).

Own package mirrors where packages are re-built by ourselves. Adding external public repositories is simply not allowed.

Re: Jujutsu at Google [video]

#196

Post by martinvonz »

1718627440 wrote: post #192
martinvonz wrote: post #186

Earlier quoted context omitted.

> I just resolve them? I think I don't understand this question. In order to make changes to commit A when there are conflicting changes in B, I was thinking that you would have to use interactive rebase instead because you can no longer make those changes in the working copy and use `git commit --fixup`, right? And because there will now be conflicts in commit B, you will be in this "interrupted rebase" state where…

> I was thinking that you would have to use interactive rebase instead because you can no longer make those changes in the working copy and use `git commit --fixup`, right? And because there will now be conflicts in commit B, you will be in this "interrupted rebase" state Yes. I don't see the drawback honestly. Invoking git rebase, means I want to resolve conflicts now, when I want to do that later, I can just call g…

The difference is that jj doesn't force you to resolve the conflict right away. I agree that you usually want to do that anyway, but it has happened to me many times that some conflict turned out to be more complicated than I had time for at the moment and I needed to work on something else for a while. When using Git, I would typically abort the rebase in such cases, which is not so bad if you have rerere enabled (I can't remember if it records any resolutions I had staged or if that's only one you commit).

Anyway, I'm just explaining how jj works and what I prefer. As Steve always says, you should use the tools you prefer :)

Re: Jujutsu at Google [video]

#197

Post by 1718627440 »

martinvonz wrote: post #196
1718627440 wrote: post #192

Earlier quoted context omitted.

> I was thinking that you would have to use interactive rebase instead because you can no longer make those changes in the working copy and use `git commit --fixup`, right? And because there will now be conflicts in commit B, you will be in this "interrupted rebase" state Yes. I don't see the drawback honestly. Invoking git rebase, means I want to resolve conflicts now, when I want to do that later, I can just call g…

The difference is that jj doesn't force you to resolve the conflict right away. I agree that you usually want to do that anyway, but it has happened to me many times that some conflict turned out to be more complicated than I had time for at the moment and I needed to work on something else for a while. When using Git, I would typically abort the rebase in such cases, which is not so bad if you have rerere enabled (I…

> When using Git, I would typically abort the rebase in such cases, which is not so bad if you have rerere enabled

Yes, I do the same. I think it's not too different. You can also commit randomly somewhere else, it is only a problem once you try to start another rebase or merge. (But I never needed to do it, I just tried it out during discussions like this.)

> Anyway, I'm just explaining how jj works and what I prefer. As Steve always says, you should use the tools you prefer :)

Sure. I'm not objecting to you using JJ, I was objecting to you stating, that it is "much harder" in Git. This is seems to be a common sentiment among JJ users, but it always seem to amount to that people bother to read the manual and understand the tool AFTER they used a VCS for years.

Re: Jujutsu at Google [video]

#198

Post by martinvonz »

1718627440 wrote: post #197
martinvonz wrote: post #196

Earlier quoted context omitted.

The difference is that jj doesn't force you to resolve the conflict right away. I agree that you usually want to do that anyway, but it has happened to me many times that some conflict turned out to be more complicated than I had time for at the moment and I needed to work on something else for a while. When using Git, I would typically abort the rebase in such cases, which is not so bad if you have rerere enabled (I…

> When using Git, I would typically abort the rebase in such cases, which is not so bad if you have rerere enabled Yes, I do the same. I think it's not too different. You can also commit randomly somewhere else, it is only a problem once you try to start another rebase or merge. (But I never needed to do it, I just tried it out during discussions like this.) > Anyway, I'm just explaining how jj works and what I prefe…

> it always seem to amount to that people bother to read the manual and understand the tool AFTER they used a VCS for years.

Perhaps, but I don't think that's true for me (or for Steve). I've contributed something like 90 patches to Git itself (mostly to the rebase code). To be fair, that was a while ago.

My impression is actually that many people who disagree with the sentiment that jj is much easier to use seem to have not read its manual :) Some of them seem to have not even tried it. So, the way it looks to me, it's usually the people who argue for jj who have a better understanding of the differences between the two tools.

Have you tried jj yourself and/or have you read some of the documentation?

Re: Jujutsu at Google [video]

#199

Post by 1718627440 »

martinvonz wrote: post #198
1718627440 wrote: post #197

Earlier quoted context omitted.

> When using Git, I would typically abort the rebase in such cases, which is not so bad if you have rerere enabled Yes, I do the same. I think it's not too different. You can also commit randomly somewhere else, it is only a problem once you try to start another rebase or merge. (But I never needed to do it, I just tried it out during discussions like this.) > Anyway, I'm just explaining how jj works and what I prefe…

> it always seem to amount to that people bother to read the manual and understand the tool AFTER they used a VCS for years. Perhaps, but I don't think that's true for me (or for Steve). I've contributed something like 90 patches to Git itself (mostly to the rebase code). To be fair, that was a while ago. My impression is actually that many people who disagree with the sentiment that jj is much easier to use seem to…

I wanted, but it didn't compile due to needing a newer Rust compiler, than is available in my Distro. And the tutorials I found told me to run the equivalent of curl|bash, which I will not do. I don't felt like learning a new language/ecosystem just to try out another VCS, so I said, it's not worth it, I wait until it is available in my distro.

So actually no, and you have a point. :-)

I often just read "this is hard in Git" and think isn't this just this command? JJ has some nice features, but what appeals to me seems to not to be that hard to add to Git, so I will just wait a bit.

Re: Jujutsu at Google [video]

#200

Post by sfink »

1718627440 wrote: post #193
sfink wrote: post #99

Earlier quoted context omitted.

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. Com…

> But you're kind of fighting against the grain to do it. > `jj absorb` git absorb exists.

It may be unclear since I screwed up the formatting of my post, but that's why I didn't end there. The rest of jj's capabilities change when and how I use it.

The absorb command originated in mercurial, which is where I've used it most. With `hg absorb`, I'd only use it when I was fairly sure that it would do the right thing, and I imagine it'd be the same with git. With jj, having `jj undo` as a fallback means I can use it just to see what it does and if it gets something wrong, undo it and do what I want in a different way. (But not that different -- `jj squash -i --into X` means I can do the same thing as it was doing manually.)

Post reply on HN