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

Jujutsu for busy devs

maddie.wtf

Post reply on HN
Print view View original

361–370 of 552 posts

Re: Jujutsu for busy devs

#361

Post by nchmy »

palata wrote: post #335
nchmy wrote: post #293

Earlier quoted context omitted.

I've started, in this thread, likening it to Plato's Cave - people who are just using git are just seeing/using a blurry facsimile/projection of actual reality/possibilities. It's not a perfect analogy (jj is, I suppose, the projection, and people are chained in the cave), but it makes the point that there could be so much more. The matrix or people happily in a cult would be similar analogies. Perhaps even Stockholm…

This is exactly why it feels like evangelism: "people who don't love jj haven't seen the light/are uninformed/live in the dark age/must be in a cult". That kind of rhetoric makes me want to say "don't tell me I'm stupid if you are the one finding it hard to switch between git branches".

That's fine. Carry on

Re: Jujutsu for busy devs

#362

Post by packetlost »

deredede wrote: post #120
packetlost wrote: post #51

Earlier quoted context omitted.

If you have 5 different branches, sure. Again, the reason you create a bunch of branches for separate review is because that's what the "git forge" abstraction generally expects. It's not actually how code reviews are done by the people who wrote it. You can also just enable that feature (rerere).

> It's not actually how code reviews are done by the people who wrote it. What do you mean by that? Even if you do review by emailing patchsets those are still managed locally using branches, to my knowledge.

I mean the unit of review is the patch (set), which does not necessarily have a branch associated with it. You can use a branch, but you could just as easily send commits from master and the reviewer can apply them directly on their master branch if desired. The idea of "branch per reviewable unit" was largely created by GitHub.

Re: Jujutsu for busy devs

#363

Post by nchmy »

stavros wrote: post #304
nchmy wrote: post #289

Earlier quoted context omitted.

I have a bad habit, even still, of just working in one monster commit. It took me a few months to realize that I could use jj split to move specific files to a different commit. And then I'd sometimes squash them into related commits, rebase to move them around etc... But I just discovered interactive split, which lets you move specific lines and sections from different files in a commit to a different commit. So I'v…

Interactive split?! Very interesting, I'll look into that, thanks! EDIT: I love it.

Haha, fantastic.

Also, if you didn't discover yet, you can use the arrow keys to unfold the different files and sections. Then select what you need, split the rest to new commit.

As you know, even when just using the most basic functionality (new changes, merges, rebases) of jj, it's amazing. But then you just keep discovering other features and workflows - none of which require any incantations - that make it that much better. And I'm sure I'm still only scratching the surface of its possibilities.

And, as I keep saying everywhere, jjui just takes the whole experience to another level.

Re: Jujutsu for busy devs

#364

Post by packetlost »

wredcoll wrote: post #109
packetlost wrote: post #51

Earlier quoted context omitted.

If you have 5 different branches, sure. Again, the reason you create a bunch of branches for separate review is because that's what the "git forge" abstraction generally expects. It's not actually how code reviews are done by the people who wrote it. You can also just enable that feature (rerere).

What is the "right" way to do it then? Also probably most of us are stuck with whatever git*.com supports anyways...

Basically see how the LKML works. Individual commits are typically expected to be self-contained to the best extent possible, with patch sets or patch series being used when that's not feasible. Patches are usually sent over email, but there are a lot of ways to do it.

It's not an ideal way to operate for most shops, but there's really no reason you can't have a PR/MR/changelist/whatever that is a single branch with X commits on it and you ask the reviewer to review each commit individually instead of as a whole unit (as GitHub and other forges usually expect you to).

That and don't let reviews pile up such that you have 5 dependent in-flight reviews, something else is wrong if that's happening.

Re: Jujutsu for busy devs

#365

Post by Zambyte »

palata wrote: post #358
Zambyte wrote: post #354

Earlier quoted context omitted.

> because there's no single thing that you can do with jj that you can't with git. - jj undo, jj op restore, and jj --at-op to reset or view the repo at a previous state - create multiple directories (workspaces) backed by a single repository at different commits These are the only things I can think of off the top of my head that you can do with jj that you can't do with git.

> to reset or view the repo at a previous state What about `git reflog`?

That lets you see previously checked out revisions. Jujutsu keeps track of all previous repo state. In git, you can pull a new remote branch, delete that branch, and push the deletion. If you want to get that branch back, git reflog will only save you if you checked out that commit. If you didn't, you're SOL. Jujutsu will let you undo the delete operation, restore the repo to a state where the branch existed, or view the repo at a state where the branch existed, and create a new branch at the same revision that the old branch was before it was deleted.

Re: Jujutsu for busy devs

#366

Post by nchmy »

koakuma-chan wrote: post #319
nchmy wrote: post #201

Earlier quoted context omitted.

jj itself is tooling built around git repos... It just works seamlessly with any git repo. And there's toppling built around jj, such as jjui https://github.com/idursun/jjui

Oh --colocate is what I needed.

Yup! And you can just do jj git init --colocate in an already-cloned repo and it'll start working immediately, seamlessly. No need to re-clone it via jj git clone --colocate

Re: Jujutsu for busy devs

#367

Post by kps »

1718627440 wrote: post #172
wredcoll wrote: post #104

Earlier quoted context omitted.

> My concern isn't just about pushing upstream. What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate that it's ready Since you brought this up, I've noticed some people seem to work this way but I've never found anyone to ask why they do this. I get the idea behind clean, readable git logs with nice consistent messages, but isn't that what rebase/amend is for?…

I also work this way. A commit is really about, well, committing that these are exactly the right lines of code I intended to write. I also read them in another program, so it gets easier to not think that I already know the code and skip over. I basically start from the clean state (no changes) again and approve the changes line-by-line according to whether they fit the domain model of the program, whether they are…

>A commit is really about, well, committing that these are exactly the right lines of code I intended to write.

That would be a ‘change’ in jj. A commit in jj is more like SQL than git; it's the end of a transaction, not a value judgement.

Re: Jujutsu for busy devs

#368

Post by theappsecguy »

amomchilov wrote: post #312
tomasyany wrote: post #266

Don't want to sound old school, but git works perfectly fine. The learning curve might be a bit difficult, but afterwards everything makes sense. And let's be honest, you just need a few actions (pull, add, reset, branch, commit) to use it in 95% of the cases.

Stacked diffs are a core part of my workflow, letting me “work ahead” without being blocked waiting for reviews. Setting them up in git is not to bad. Adding a change to the bottom of the stack, and restacking everything on top… that’s hell in git.

Try git-spice!

Re: Jujutsu for busy devs

#369

Post by nchmy »

pjmlp wrote: post #330
nchmy wrote: post #326

Earlier quoted context omitted.

Ok, so I'm just having trouble seeing how your situation is at all relevant to this discussion about the merits of jj. You simply have to use what you're assigned.

It isn't, you decided it was, reposting my comment. > If I had an option, I would still be using something like Subversion or Mercurial. > As it is, I go with whatever our clients require of us, and that isn't jj. I share no desire to use jj in those words.

But how is that a relevant comment for this post about jj? People are talking about one thing and you're saying "I either can't use it at all, or am just happy with something else already". There was no discussion of the merits or shortcomings of jj...

All I was saying is that if a client requires you to use git, you could use jj without them knowing/caring - unless your entire workstation is under tight control, in which case, again, it's not relevant to the discussion

Re: Jujutsu for busy devs

#370

Post by packetlost »

KingMob wrote: post #247
frizlab wrote: post #165

Earlier quoted context omitted.

I think you communicated well, probably I did not. > suspending the rebase and going to do something else This is what I find to be weird, personally. When doing a rebase, there’s no way I want to do something else in the middle of it, and having a modal state feels totally natural to me. At first approach (I read a (very good) intro[1]; I did not try), it seems there’s a lot of new things to learn (for instance the…

I think the evergreen use case for interrupting a rebase is, your manager came over to ask if you can drop everything and look at this bug that $TOP_CLIENT is screaming about. Git worktrees suffice, but they're still heavier weight than `jj new whatever`.

I've had maybe 3-4 occasions in my entire career where I was working with a rebase large enough where it took multiple sittings (every single one sucked badly). I'm not going to argue that it's not something that comes up, but I will say that if it's common, your workflow is probably too chaotic for me. That being said, you can still do that in git (see sibling comment to this one), but it is more involved. IMO that's good because I don't think enabling that type of chaotic, jumpy workflow is healthy or good.
Post reply on HN