Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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

This is a consequence of rebases being a special, modal state that requires dedicated focus to work through to resolution.

Rebase conflicts are (to a jj user) just another fix you might want to make to a revision. Or it might be better done by making a tweak to an earlier revision, instead of the revision where the conflict first occurred. There’s no pressure to fix it right this second, you can always come back where you left off. And you can make your fixed in a separate commit that you squash into the conflicted commit if it’s particularly hairy.

> It feels like jj is solving a lot of problems that do not exist, or are mostly solved with worktrees.

Git has grown a lot of features over the years and countless flags to make some things feasible.

jj rethinks the core interaction model in a way that gets rid of all the band-aids.

There are people who still live and die by C and swear that anyone running into issues is holding it wrong or just needs to be more principled about how they handle memory. But most people have moved on to higher-level languages. It doesn’t mean C was a bad language, it doesn’t mean those programmers weren’t familiar with C, and it doesn’t mean there aren’t still some cases where C is the right answer. But most people nowadays find other languages more productive with less friction.



> This is a consequence of rebases being a special, modal state that requires dedicated focus to work through to resolution.

Believe it or not: no. Humans are notoriously bad at multitasking, so it makes sense to actually finish a task before moving to something else and forgetting what we were doing…

Relaxing this comment which is a bit aggressive: at least it’s how I work. YMMV.


> Believe it or not: no. Humans are notoriously bad at multitasking, so it makes sense to actually finish a task before moving to something else and forgetting what we were doing…

Again, see my other comment. It's like saying "Humans are bad at multitasking - they should never switch to another branch until the current feature is done."


> it's like saying "Humans are bad at multitasking - they should never switch to another branch until the current feature is done”

Neither. Rebasing is an atomic task, kinda like a commit.


> Rebasing is an atomic task

I may be misinterpreting your position, but I suspect you consider rebasing and fixing conflicts together as the atomic task. In jujutsu, these are two separate tasks. You do a rebase. Even if there are conflicts, the rebase is done. Fixing conflicts is its own task, and can be done at your leisure - no need to couple the two.

It's like writing some code that broke a test. You don't say "Hey, I'd rather not work on anything else until this is fixed." If you want, you either commit it as is (or stash if you prefer), work on something else, and come back to it later to fix the broken test.


> You don't say "Hey, I'd rather not work on anything else until this is fixed."

Hey that’s where we differ I guess! I do (most of the time, and if I truly need to switch, my workspace is cloned usually at least twice, using worktrees, so I can indeed switch whatever the current status of everything).

This is broadly what I was saying above, most of the “problems” git have are solved with worktrees, that have the undeniable advantage (IMHO) to actually separate tasks, instead of being in a state where (waving hands) everything is here in this big bowl of stuff (and I’m not saying that dismissively; once again everybody works differently; it’s just not my thing).

I do have understood the “conflicts do not need to be resolved straight away,” though I do not really get it (if there are conflicts the code does not compile anymore, so what is even the point? ok you can switch branch, but still it’s a task that I would know I have to do anyway and I could not switch to something else; my brain does not work that way).

All of that being said, since you seem to know a lot about jj, I’ll take the liberty to ask a question I do have about it, because there is indeed a workflow that I find painful with git that, IIUC, is actually solved by jj.

Let’s say I (or the team) am (is) working on two or three different things on two or three different branches. The full feature is the merge of these branches. Is jj able to maintain a branch which is the merge of all the other branches mostly (or fully) automatically?


Actually, my experience is still at the beginner level - I switched only weeks ago.

If you have 3 branches, you can create a new node that is the merge of all 3. But your question is will it keep up with the changes.

If all 3 branches are local to your machine, and have not been shared, and you edit a prior commit, then all descendants are rebased and thus that merged node will get the changes - no new merges needed.

I think your real question, though, is if one of the branches gets a new child node, can we have the merged node dynamically merge from the new child, rather than from its parent?

I honestly don't know - but I actually do have a need for this! jj has bookmarks, and you can create a merge using bookmarks, but whether the new node will autoupdate if the bookmark moves - something I'd need to experiment with.

Finally, when you have shared/pushed your code, jj will treat shared nodes as immutable, so some fancy jj stuff becomes disallowed.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: