Hacker News Reader

Comment by nchmy | Hacker News Reader

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've been using that a lot more recently to organize the changes more thematically.

Ultimately I should try to become more diligent with adding a new commit any time I start doing something different - it's dead simple to do and even less friction to organize later - but I suppose that I'm not that inclined because the interactive split makes it so easy to do it all later that I just stay in the flow of my monster commits.

Everything is possible with jj.

just started making much more use of jj split to move split

View on HN

One really nice trick you can do is:

- Create multiple topic branches, one for each thing you're working on.

- Now you probably want to work on item A while having B and C all available, so make a single merge commit (jj new a b c) to build on top of.

- Create further commits on top of that, while you're working.

- When you're cleaning up (ideally often), use squash --to or rebase --after to move those commits back the branch they belong on. This does not invalidate the merge commit; you will, effectively, have multiple branches checked out at once.

EDIT: This is apparently called the 'megamerge workflow'.

Megamerges are awesome, but what really makes them magical is when you start using `jj absorb`, which automatically splits and squashes your commit down to the nearest unambiguous commits and leaves anything that doesn't have an obvious place to live

I've been trying absorb recently and have found it rarely does anything and I just resort to squashes. Any idea what might be going on?

Absorb:

- Will not rewrite an immutable commit, of course. (Though you can tell it to, and for my personal repositories I sometimes actually set immutable() = root().)

- Will not do anything to diffs if it's uncertain where they should go, either because that file wasn't edited in a previous mutable commit, or because it was edited in multiple sibling/cousin commits. The latter is likely to happen with mega-merges.

You can use --into to restrict the set of target commits, if you already know what feature branch you're updating.

Yeah, I was already aware of megamerge. I use it.

But I'm still not disciplined enough to use it and other proper workflows consistently, especially when new features/topics spring up while working on another one. I just start working on it at the same time, and jj makes it simple to split it into its own commit and branch later.

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.

If you end up with a commit that's a number of small fix-ups to files edited in earlier commits, `jj absorb` will push changes up to whichever (mutable) commit last modified the file they're in.

Thanks. I've been trying it recently but it never seems to do anything, so I just do squashes. Any idea why this might be?

Reply on news.ycombinator.com