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

The Jujutsu version control system

neugierig.org

Post reply on HN
Print view View original

11–20 of 52 posts

Re: The Jujutsu version control system

#11

Post by fragmede »

gcr wrote: 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…

I use git add -p to deal with that particular issue, but it's great that other people are making and finding tools that work for them.

Re: The Jujutsu version control system

#12

Post by fprotthetarball »

akdor1154 wrote: post #4

Great article. How do people deal with the lack of branches, esp in a full time setting where it's common to have a few independent features on the go?

There are still branches, but they aren't named by default. You give them names with "bookmarks", which you can push to remote git repositories as branches.

This lets you work on things without having to worry about giving it a name. This turns out to be pretty helpful when you're experimenting — just "jj new " and start editing. If it turns out to be something you want to share, "jj bookmark create " and then you can push it. (You can also push without giving it a name, in which case you'll get a git branch with a name based off of the change id.)

Change IDs stay constant with each change, so you use those as a type of branch name when switching between the features you're working on.

Re: The Jujutsu version control system

#13

Post by CharlieDigital »

bsder wrote: post #5
forrestthewoods wrote: post #2

I’m quite happy with Sapling at work. I still haven’t figured out what Jujutsu does better. I think nothing substantial? Not that Sapling can be easily used in the public sphere. But at a conceptual level I’m not sure there’s anything in JJ I’m missing.

Sapling is Mercurial with some advancements. Mercurial is ridiculously better than git, but lost the network effects battle due to Github. So, JJ probably doesn't give you anything amazing. JJ is useful for those of us who understand the shittiness of Git but have to work in a world that got locked into path dependent network effects by VC money.

From the blog:

    > When I left Google three years ago I recall they were trying to figure out what to do about either making Git scale, or adopting Mercurial, or what.
It's interesting because I used Mercurial (hg) for close to a decade after coming from Subversion.

Rarely had to consult the docs for weird edge cases and generally operation felt natural and seamless. It was easy to onboard new devs of all experience levels.

I switched to git 5 years back and I still feel lost sometimes and inadvertently end up in detached head state once in a while. Git feels really "unnatural" or "unintuitive" to me in some way that Mercurial never did (I can't put my finger on why because I never gave Mercurial much thought).

Re: The Jujutsu version control system

#14

Post by miki123211 »

gcr wrote: 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…

> It feels way more natural, especially for newer users.

I have thought about this recently, and it feels like jj would be a lot easier to teach to new users than git.

For one, jj lets you work on things directly without having to worry about an index, while still giving you all the advantages of one if you're advanced enough to need that.

THe commands also feel a lot easier to explain than in git. For example, you use `edit` to change what commit you're working on, `restore` to copy a file from a commit to your working directory (and abandon your changes to it), and `abandon` to drop a commit completely. Meanwhile, git has `checkout`, `restore`, `switch`, `reset` and `reset --hard`, which all do various parts of one or more of these.

Re: The Jujutsu version control system

#15

Post by 3eb7988a1663 »

miki123211 wrote: post #14
gcr wrote: 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…

> It feels way more natural, especially for newer users. I have thought about this recently, and it feels like jj would be a lot easier to teach to new users than git. For one, jj lets you work on things directly without having to worry about an index, while still giving you all the advantages of one if you're advanced enough to need that. THe commands also feel a lot easier to explain than in git. For example, you u…

Reading the jj changelog is fun where you see them deprecate functions, acknowledging that they perform identical purposes. Beautiful to see this simplification that benefits all users going forward.

The one that stood out in my mind:

  `jj checkout` and `jj merge` are both deprecated; use `jj new` instead to replace both of these commands in all instances.

  Rationale: jj checkout and jj merge both implement identical functionality, which is a subset of jj new. checkout creates a new working copy commit on top of a single specified revision, i.e. with one parent. merge creates a new working copy commit on top of at least two specified revisions, i.e. with two or more parents.

  The only difference between these commands and jj new, which also creates a new working copy commit, is that new can create a working copy commit on top of any arbitrary number of revisions, so it can handle both the previous cases at once. The only actual difference between these three commands is the command syntax and their name. These names were chosen to be familiar to users of other version control systems, but we instead encourage all users to adopt jj new instead; it is more general and easier to remember than both of these.

Re: The Jujutsu version control system

#16

Post by samatman »

bsder wrote: post #5
forrestthewoods wrote: post #2

I’m quite happy with Sapling at work. I still haven’t figured out what Jujutsu does better. I think nothing substantial? Not that Sapling can be easily used in the public sphere. But at a conceptual level I’m not sure there’s anything in JJ I’m missing.

Sapling is Mercurial with some advancements. Mercurial is ridiculously better than git, but lost the network effects battle due to Github. So, JJ probably doesn't give you anything amazing. JJ is useful for those of us who understand the shittiness of Git but have to work in a world that got locked into path dependent network effects by VC money.

Git succeeded to large degree because of GitHub, yes. But that isn't how it happened at all. They built an amazing product that people loved, there was nothing even vaguely like it before, and it earned its adoption through providing a superior product than the competition, by leaps and bounds.

It ended on a bitter note when Microsoft bought them, sure. But let's not rewrite history, GitHub was not dumped on the market by deep-pocketed VCs. GitHub was self-funded from 2007 to 2012, at which point it was wildly popular and used a big cash injection to get to where it is now. By the time that happened it had the #1 position in commits per month and was about to become #1 in repos hosted also.

Re: The Jujutsu version control system

#17

Post by ibejoeb »

fragmede wrote: post #11
gcr wrote: 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…

I use git add -p to deal with that particular issue, but it's great that other people are making and finding tools that work for them.

Same. I love the power and flexibility. But, then again, I sometimes found myself spending a nontrivial amount of time planning my git maneuvers. That was a bit taxing. Either it took away from the focus on the objective, or it was enough of a chore that it I felt a little worn, especially during intense working sessions. I don't get that as much with jj.

Re: The Jujutsu version control system

#18

Post by J_tt »

fprotthetarball wrote: post #12
akdor1154 wrote: post #4

Great article. How do people deal with the lack of branches, esp in a full time setting where it's common to have a few independent features on the go?

There are still branches, but they aren't named by default. You give them names with "bookmarks", which you can push to remote git repositories as branches. This lets you work on things without having to worry about giving it a name. This turns out to be pretty helpful when you're experimenting — just "jj new " and start editing. If it turns out to be something you want to share, "jj bookmark create " and then you ca…

Adding onto this, there’s also an experimental feature to move a bookmark as you create new revisions (similar to how a git branch behaves)

Re: The Jujutsu version control system

#19

Post by sunshowers »

CharlieDigital wrote: post #13
bsder wrote: post #5

Earlier quoted context omitted.

Sapling is Mercurial with some advancements. Mercurial is ridiculously better than git, but lost the network effects battle due to Github. So, JJ probably doesn't give you anything amazing. JJ is useful for those of us who understand the shittiness of Git but have to work in a world that got locked into path dependent network effects by VC money.

From the blog: > When I left Google three years ago I recall they were trying to figure out what to do about either making Git scale, or adopting Mercurial, or what. It's interesting because I used Mercurial (hg) for close to a decade after coming from Subversion. Rarely had to consult the docs for weird edge cases and generally operation felt natural and seamless. It was easy to onboard new devs of all experience le…

You're like most developers! The core problem is that Git's workflow treats branches as the source of truth for what's in the repo, while Mercurial and its progeny (Jujutsu and Sapling) treat individual commits as the source of truth. The latter is vastly simpler, and also (as Jujutsu shows) more powerful.

While working on a stack of changes, you should be able to check out an earlier commit, amend it, and have its descendants be automatically rebased. Of course you should be able to -- this is a natural and straightforward way to think about working on changes, and builds on prior knowledge about how to work with individual commits and how to rebase them onto a newer upstream. Now compare this to git rebase -i.

Re: The Jujutsu version control system

#20

Post by adastra22 »

gcr wrote: 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…

You can edit your commit message ahead of time in git too.
Post reply on HN