Live data from Hacker News

The Jujutsu version control system

neugierig.org

51–52 of 52 posts

Re: The Jujutsu version control system

#51
post #28

Earlier quoted context omitted.

It's no different from how rebasing works in any shared git project; rebased commits are re-created with different SHAs.

Right but that doesn't address the collaboration issue: who gets to decide where the branch points to?

In jj, pulled commits are immutable by default. Commits that you author are mutable until you push them.

If I'm on a project with change AAA -> BBB, suppose my friend authors CCC and I author DDD.

So my history looks like:

    AAA  ---->  BBB  ---->  DDD
    (immutable) (immutable) (mutable)
And my friend's has:

    AAA  ---->  BBB  ---->  CCC
    (immutable) (immutable) (mutable)
But then my friend pushes their change first. So when I pull, I'll have:

    AAA -> BBB -> CCC (immutable)
            \
             '-> DDD (mutable)
Just like git, I then rebase my commit by saying `jj next` (mnemonic: "move this commit to its next descendant") to get

    AAA -> BBB -> CCC (immutable) -> DDD (mutable)

Re: The Jujutsu version control system

#52
post #7
post #3

I use jj for all my projects on github! It's really useful for my sort of workflow: chains of commits with easily-editable history. If you make a change back in time, you edit the previous commit (which puts you in a state similar to git's detached head), and any edits you make there are automatically carried forward (rebased) onto descendants. It feels way more natural, especially for newer users. The killer feature…

This might be the single most compelling reason I’ve ever read to try jj. I won’t, but thanks for this particular feedback.

I've yet to try jj, but in git, my flow is to start a new feature with a WIP commit and then to `--amend` it with every change. I usually have a running TODO list in the commit message body that I check off along the way.
Post reply on HN