6 ms·

Will this have any chance if Jujutsu/jj doesn't get more traction? The effort to learn a new VCS is less than for a programming language, but many developers ha

by drsouth 15d ago

Will this have any chance if Jujutsu/jj doesn't get more traction? The effort to learn a new VCS is less than for a programming language, but many developers have not learned git in depth, and Mercurial and others have not gained a lot of traction.

onion2k 15d ago
many developers have not learned git in depth They have less to walk away from then.
Shish2k 15d ago
> many developers have not learned git in depth TBH learning git in depth was a hindrance for me learning jj - for my first few weeks I kept instinctively looking for complex solutions to simple problems and being confused, when the answer was always "use the tools you already know" As a concrete example - git has one set of commands for managing commits, a different set of commands for managing the index, a third set of commands for managing stashes, a fourth set of commands for managing the working directory, and a fifth set of commands for managing conflicts -- in jj all of those things are a single concept with a single set of commands, equally (if not more) powerful, but also simpler
Kinrany 15d ago
It doesn't require that everyone switch at the same time, unlike other VCSs.
saghm 15d ago
I'd argue that the reason a lot of developers have not learned git in depth is because it's actually kind of terrible from a UX standpoint (lots of inconsistent naming of things and somewhat leaky abstractions), and that Mercurial faced an uphill battle in large part because it lacked compatibility with what people were already using. I haven't used Mercurial, but from what I've heard quite a lot of how jj does things is similar to Mercurial, just in a way that's compatible with git. I haven't used git directly for over a year in favor of using jj despite exclusively using git repositories, and no one I've worked with has even needed to be aware.
- pjmlp 15d ago
  As a Mercurial fanboy, git took off thanks to being from Linus, and a requirement to contribute to the Linux kernel, from there the adoption wind was in motion.
  - p_l 15d ago
    As someone who was a mercurial fanboy too, critical element was that Github happpened for git while mercurial had nothing comparable - and before anyone points at bitbucket, it fucking sucked in UX
    - pjmlp 15d ago
      Yet UX wasn't a problem for Git adoption.
      - p_l 14d ago
        It was huge problem for Git adoption, that's why I mentioned GitHub EDIT: GitHub had probably the first UX where I actually liked what I got, compared to various earlier git based ones, or the horrible CVS and SVN ones where clicking on a file name definitely didn't do what you expected. I barely remember Bitbucket from the mercurial era but I do recall that while it was better than some, it was still worse than GitHub, whose "here's default branch's HEAD, plus auto-opened and formatted README" was really a game changer
  - yencabulator 14d ago
    As an ex BitKeeper fanboy with a history all the way to RCS, Git was just better.
    - pjmlp 14d ago
      Better than Bitkeeper maybe. I also have used plenty of SCM systems since mid-90's.
- skydhash 15d ago

by drsouth 15d ago

onion2k 15d ago

many developers have not learned git in depth They have less to walk away from then.

Shish2k 15d ago

> many developers have not learned git in depth TBH learning git in depth was a hindrance for me learning jj - for my first few weeks I kept instinctively looking for complex solutions to simple problems and being confused, when the answer was always "use the tools you already know" As a concrete example - git has one set of commands for managing commits, a different set of commands for managing the index, a third set of commands for managing stashes, a fourth set of commands for managing the working directory, and a fifth set of commands for managing conflicts -- in jj all of those things are a single concept with a single set of commands, equally (if not more) powerful, but also simpler

Kinrany 15d ago

It doesn't require that everyone switch at the same time, unlike other VCSs.

saghm 15d ago

I'd argue that the reason a lot of developers have not learned git in depth is because it's actually kind of terrible from a UX standpoint (lots of inconsistent naming of things and somewhat leaky abstractions), and that Mercurial faced an uphill battle in large part because it lacked compatibility with what people were already using. I haven't used Mercurial, but from what I've heard quite a lot of how jj does things is similar to Mercurial, just in a way that's compatible with git. I haven't used git directly for over a year in favor of using jj despite exclusively using git repositories, and no one I've worked with has even needed to be aware.

pjmlp 15d ago
As a Mercurial fanboy, git took off thanks to being from Linus, and a requirement to contribute to the Linux kernel, from there the adoption wind was in motion.
- p_l 15d ago
  As someone who was a mercurial fanboy too, critical element was that Github happpened for git while mercurial had nothing comparable - and before anyone points at bitbucket, it fucking sucked in UX
  - pjmlp 15d ago
    Yet UX wasn't a problem for Git adoption.
    - p_l 14d ago
      It was huge problem for Git adoption, that's why I mentioned GitHub EDIT: GitHub had probably the first UX where I actually liked what I got, compared to various earlier git based ones, or the horrible CVS and SVN ones where clicking on a file name definitely didn't do what you expected. I barely remember Bitbucket from the mercurial era but I do recall that while it was better than some, it was still worse than GitHub, whose "here's default branch's HEAD, plus auto-opened and formatted README" was really a game changer
- yencabulator 14d ago
  As an ex BitKeeper fanboy with a history all the way to RCS, Git was just better.
  - pjmlp 14d ago
    Better than Bitkeeper maybe. I also have used plenty of SCM systems since mid-90's.
skydhash 15d ago