Thanks for the reply Steve - I think it's only natural, and charitably unintentional :) But almost everything I've seen upvoted around the Internet from you has been about jj and being directly tied to east river source control... I think that's a reasonable framing. I can only hope me signalling this maybe changes something. While I'm not a fan of jj (I'd much rather Pijul were to eat the world), I think you as a person is really nice and always have been "for the community", but I can't shake this current framing!

I'm sorry, it's hard to say anything good about a project that brings nothing new to the table while desperately trying to replace a well-established industry standard. Such attempts look annoying at best and irritating at most. At the very least the person behind the project could have been more humble in pushing it, and instead of presenting it as a "git killer" causing everyone only headache he could have had 1) polished it 2) pointed out precisely what "problems" with git his project solves. None of those were clearly stated; instead, the shared page is simply a shameless plug for wasting everyone's time.

Okay, next time I'm simply going to ignore it, but allowing this kind of posting only works against the HN. I'm not sure if you've noticed, but even the original post title was annoying enough that someone from the moderators had to replace it.

Not necessarily. I used jj for a couple of weeks and found it to be a complete waste of time.

For an advanced user, it did not offer anything I cannot quickly solve in git. Which is probably the wrong thing to optimize in the first place, because even though I frequently rewrite history and split commits during normal worklfow, it takes so little time that improving something else would yield greater returns.

We (not royal we) don't usually go out of our way repeating negative experiences with these tools, so you build a very skewed view of their adoption.

Their opinion is great, why do you feel like you need to counter it with [but, but jj is for the clean masses, not the unclean users].

IMO Subversion was never as much of a standard as git. I saw a lot of software that still used CVS back then, and even more that didn't do version control beyond versioned source tarballs.

I'd be happy to be proven wrong. You won't get there by designing a solution that is more ergonomic (if jj even is), but rather by designing one that solves problems that git doesn't solve. Also, you probably need to get some big and important software (like Linux, for git) to switch to using it instead of git.

Even then, I'm usually _not_ an early adopter of something as pivotal as a VCS. This isn't something that's easy to rip out or rewrite later. It shapes my workflow at a deep level and holds the history of my changes in its database. Only once it's being used by 25-50% of projects I encounter daily will I consider moving stuff I control to it.

I have deep scars from mercurial lol.

Coming from mercurial (which is older than git), git doesn't understand a branch. Instead of a branch you get a tag that moves, which is very different. Too often I'm trying to figure out where something came in, and but there is just a series of commits with no information of which commits are related. Git then developed the squash+rebase workflow which softof gets around this, but it makes commit longer (bad), and loses the real history of what happened.

Git was not the first DVCS, there were better ones even when it was made. But Linus pushed git and people followed like sheep.

(I'm using git, both because everyone else is, and also because github exists - turns out nobody even wants a DVCS, they want a central version control system with the warts of SVN fixed).

Git is basically fine even though the verbs are backwards - e.g. you shouldn't need to name branches, commits should be far more automatic, but the basic mechanisms are fine.

GitHub is an abomination.

Right.

How we got git was cvs was totally terrible[1], so Linus refused to use it. Larry McEvoy persuaded Linus to use Bitkeeper for the Linux kernel development effort. After trying Bitkeeper for a while, Linus did the thing of writing v0 of git in a weekend in a response to what he saw as the shortcomings of Bitkeeper for his workflow.[2]

But the point is there had already been vcs that saw wide adoption, serious attempts to address shortcomings in those (perforce and bitkeeper in particular) and then git was created to address specific shortcomings in those systems.

It wasn't born out of just a general "I wish there was something easier than rebase" whine or a desire to create the next thing. I haven't seen anything that comes close to being compelling in that respect. jj comes into that bucket for me. It looks "fine". Like if I was forced to use it I wouldn't complain. It doesn't look materially better than git in any way whatsoever though, and articles like this which say "it has no index" make me respond with "Like ok whatever bro". It really makes no practical difference to me whether the VCS has an index.

[1] I speak as someone who maintained a CVS repo with nearly 700 active developers and >20mm lines of code. When someone made a mistake and you had to go in and edit the repo files in binary format it was genuinely terrifying.

[2] In a cave. From a box of scraps. You get the idea.

If git would change two defaults, that would make me really happy:

  1. git merge ONLY does merges (no fast forward/rebase). git pull ONLY does a fast forward
  2. git log by default is git log --first-parent. Just show commits where the parent is the current branch. This makes the merge workflow really easy to understand an linear, because in the end, you only care about commits on the trunk.

It is not about starting over, like moving from CVS or Subversion to Git. jj is backend compatible to Git, so nothing really had to change on the backend.

It's just that although Git was created by Linus Torvalds it is not perfect and could be more beginner friendly. But efforts to improve this should be concerted, not individual efforts.

And it does not have to be jj. I just think there is room for improvement, and not to alienate old farts it could be called GitNext, GitStep, GitFlow or similar to emphasize that is still is just Git, only with an improved front end.

Maybe Linus Torvalds himself should start the initiative.