Comment by 1718627440
4 months ago
I don't like C++ either, but yes that is also my opinion about Rust. I do already annotate ownership semantics in C, so I don't know why I need a compiler that is opinionated and tells me how I should structure my code. I think Rust would invoke much less resistance, if it weren't so opinionated.
As for jj, JJ and Git are much more close than C and Rust. JJ tends to have slightly less commands, but only because what are flags in JJ are separate commands in Git. The impression I get from these posts, is that it would have been doable with similar effort in Git, but they just never bothered.
Also I prefer refining stuff we already have instead of throwing it all in the bin and stating it's obsolete.
> The impression I get from these posts, is that it would have been doable with similar effort in Git, but they just never bothered.
I don't think it would have been doable. I hear this question/comment sometimes. I sent https://github.com/jj-vcs/jj/pull/7729 to have a place to point people to.
> ### Why is Jujutsu a separate project? Why were the features not contributed to Git instead?
> The project started as an experiment with the idea of representing the working copy by a regular commit. I (@martinvonz) considered how this feature would impact the Git CLI if it were added to Git. My conclusion was that it would effectively result in deprecating most existing Git commands and flags in favor of new commands and flags, especially considering I wanted to also support revsets. This seemed unlikely to be accepted by the Git project.
This doesn't support what you said?
> I don't think it would have been doable.
This only states that JJ has a different user model, with a different structure of commands and flags, not that it magically does things that are impossible in Git.
Btw., you could just link to the commit diff instead. And are you quoting yourself?
-----------
Oops, now I see the issue, you misunderstood me.
> but they just never bothered.
"They" referred to the authors of blog posts. I didn't want to claim, that it would be a good fit to merge the JJ user model with the Git user model. My claim was that the approaches people learn with the JJ user model aren't exactly difficult in the Git model either. People just reconsider their approaches when they touch a new tool with the experience they gained since starting to use Git. They just never considered that approaches with a tool they have been using for years.
Ah, I see what you're saying now. Thanks for explaining. I agree with you in principle.
My impression from our Discord server is that quite many JJ users actually are Git experts who have been creating clean commits for years. I'm one of those people. It's not a coincidence that JJ's CLI makes it easy to create clean commits - it's designed for that from scratch.
11 replies →