One thing to note after reading into it is that jj is a VCS wrapper more than anything - that is to say, it is a frontend, and the actual VCS logic is delegated to other frameworks. Notably this...
One thing to note after reading into it is that jj is a VCS wrapper more than anything - that is to say, it is a frontend, and the actual VCS logic is delegated to other frameworks. Notably this means that it works with git repos right off the bat, which greatly increases the actual usefulness.
So I guess it's more of the "git interface rewrite" that many people have wished for.
Can you expand on that? I personally don't have much of a problem with the interface of git. Moreover, both the tutorial and the Jujutsu documentation don't really make an effort of expanding on...
So I guess it's more of the "git interface rewrite" that many people have wished for.
Can you expand on that? I personally don't have much of a problem with the interface of git. Moreover, both the tutorial and the Jujutsu documentation don't really make an effort of expanding on the tangible benefits of using it over just git.
Don't get me wrong, there are arguments being made for various use cases and features where Jujutsu might be nice. But overal I don't get the impression that it solves something fundamental in regard to git.
Edit:
I guess that my issue more or less is that a lot of the arguments seem to be “because we want a newer version because of a newer version”. In his tutorial introduction Steve links to this article where the attitude I am talking about comes forward most clearly.
It offers one possible answer to a question I first started asking most of a decade ago: What might a next-gen version control system look like — one which actually learned from the best parts of all of this generation’s systems, including Mercurial, Git, Darcs, Fossil, etc.?
On the one hand, this is a valid question. On the other hand, not everything needs to always be replaced by something “better”. Certainly in software development land, I have seen this tendency to replace things for the sake of replacing them. Often not because the thing that is being replaced is actually lacking, but because someone just wants to make a new thing or because they dislike one particular aspect.
Certainly from Google I have seen this attitude (context: The Jujutsu creator is a Google) where they often seem to be more eager to replace things like APIs and sometimes frameworks rather than maintain and expand them. without much of an explanation of why the replacement is actually needed or actually better overall.
As you noted, jj seems to be directly compatible with git, so it is less of an issue here. But git is one of the few things that has been mercifully stable and ubiquitous in the software development world, and has been for almost two decades now. While I don't think stagnation is good, I often do wish that the same was true for other aspects as well.
Sorry, I guess this grew into a bit of ranty tangent. Though the main point as far as I am concerned remains, other than it is something new I seem to be missing a big selling point for jj.
Edit2:
I guess I should expand a bit more, even though this comment is already quite long. I do realize that the article I quoted and linked does move on to say git has many issues and continues listing them. I'd also say that for the majority of people using git these are not actually issues, as most people don't work as intimately with git (or any VSC for that matter) that they need to do so. The basic concept of git that most people likely are working with is not that difficult. In fact, I suspect that the most difficult thing most people ever deal with are merge conflicts.
And at this point I get back to my rant about “things being better because newer and not explaining why”... Because further down the line I came across this remark.
The user interface is not only reasonable but actually really good: an idea borrowed from… literally every VCS other than Git.
Why though? If you call something bad and unreasonable, then you should give examples for it and not leave your audience guessing what you might mean by it.
I am honestly sick and tired of this sort of abstract arguing in software space. If you can't coherently make an argument as to why something is better, then I am not going to spend the mental effort trying out the “better” thing.
A ranty tangent isn’t so bad in this case. Sure, git has flaws, but they are definitely not bad enough for me to want to switch to anything else. With all the changes we constantly need to deal...
A ranty tangent isn’t so bad in this case. Sure, git has flaws, but they are definitely not bad enough for me to want to switch to anything else. With all the changes we constantly need to deal with, APIs, languages, frameworks, etc. I don’t mind keeping some things the same.
I'll indulge a ranty tangent, given this is directly relevant to my work. Some good excuses for rewrites: Hard dependencies on defunct external libraries No/poor maintainers Written in languages...
I'll indulge a ranty tangent, given this is directly relevant to my work.
Some good excuses for rewrites:
Hard dependencies on defunct external libraries
No/poor maintainers
Written in languages that are hard to recruit for. COBOL and Perl come to mind.
Git doesn't really suffer from much of those problems, wheras a lot of my work projects do.
It's also why I've never really dabbled in alternative shells, despite using bash constantly. Almost all of the pain points get sanded down smoothly with configs over time, while most of the new features in newer shells/utilities seem mostly cosmetic rather than functional.
New kernels and drivers written in Rust make a lot more sense than rewriting git. You can point to huge numbers of flaws in existing kernels and see tangible improvements.
Not to say it's unreasonable to try, but that if you're hoping to recruit early adopters to help, you need that good pitch, as you stated.
I'm reminded about all of these NoSQL databases, how a big draw was that you didn't need to learn SQL. But as time went on, to fix various flaws in either the engine or the API, huge subsets of SQL (and RDBMs as a whole) ends up getting tacked back on. So now there's hundreds of highly divergent unique APIs instead of fairly-universal SQL that is relatively easily ported between systems.
Nowadays there are things like Cloudstore’s Durable Objects, which have a SQLite database built in. It’s sorta similar to NoSQL since it’s effectively a SQL database per document. Lots of SQL,...
Nowadays there are things like Cloudstore’s Durable Objects, which have a SQLite database built in. It’s sorta similar to NoSQL since it’s effectively a SQL database per document. Lots of SQL, though.
I’m wondering if something like that versus perhaps Neon’s Postgres hosting would be a better way to scale. For my tiny projects, it doesn’t matter.
While cute, it is also outdated (it is over 10 years old) and very much cherry picked. Not to mention that if these inconsistencies are the biggest issue with git I'd say it is doing darn well....
While cute, it is also outdated (it is over 10 years old) and very much cherry picked. Not to mention that if these inconsistencies are the biggest issue with git I'd say it is doing darn well.
Some things mentioned there are still not as consistent as they could be, but other things have actually been improved on since then.
Which is actually part of why I am so tired of the "replacing old thing with entirely new thing" because the old thing can often be improved on itself, and often things do improve.
To quickly go over some of the points listed:
Silence: this actually is now an explicit option you can set for pull so you don't need to create an alias.
One thing well: Checkout is/was indeed overloaded with creating branches and switching branches. Since then git switch has been introduced as well as git restore
Only the gods: yeah, fair
The hobgoblin: While not entirely consistent improvements have also been made here. For example you can now do git branch --show-current. I should also note that git status is also a command that fits in this category and also has been improved over time.
The long and short of it: I suppose so, then again I was never the sort of person that relies on the command line help too much other than quick glancing. I rather have references in a separate window. For those who live in the terminal I can understand this being an issue.
I have actually written a jj "review" of sorts earlier this week, which might explain some of the pull factors for jj. It does sort of assume that people are aware of the push factors for git...
I have actually written a jj "review" of sorts earlier this week, which might explain some of the pull factors for jj. It does sort of assume that people are aware of the push factors for git though.
The tl;dr is basically fewer concepts to manage, more consistent UI (95%), and a nicer experience when working on follow work from stuff that might be revised (e.g. from a code review)
Thanks! I need to go over it in more detail but you manage to make a much better case and better explain the context. Also, given the linked tutorial and other things I came across I had thought...
Thanks! I need to go over it in more detail but you manage to make a much better case and better explain the context.
Also, given the linked tutorial and other things I came across I had thought jj to be much more mature.
Yeah, I wanted anyone interested in the tutorial to see its author's comment about how it isn't 100% up-to-date anymore. I figured linking the discussion instead of the tutorial was easier than...
Yeah, I wanted anyone interested in the tutorial to see its author's comment about how it isn't 100% up-to-date anymore. I figured linking the discussion instead of the tutorial was easier than writing my own comment about it
One thing to note after reading into it is that jj is a VCS wrapper more than anything - that is to say, it is a frontend, and the actual VCS logic is delegated to other frameworks. Notably this means that it works with git repos right off the bat, which greatly increases the actual usefulness.
So I guess it's more of the "git interface rewrite" that many people have wished for.
Can you expand on that? I personally don't have much of a problem with the interface of git. Moreover, both the tutorial and the Jujutsu documentation don't really make an effort of expanding on the tangible benefits of using it over just git.
Don't get me wrong, there are arguments being made for various use cases and features where Jujutsu might be nice. But overal I don't get the impression that it solves something fundamental in regard to git.
Edit:
I guess that my issue more or less is that a lot of the arguments seem to be “because we want a newer version because of a newer version”. In his tutorial introduction Steve links to this article where the attitude I am talking about comes forward most clearly.
On the one hand, this is a valid question. On the other hand, not everything needs to always be replaced by something “better”. Certainly in software development land, I have seen this tendency to replace things for the sake of replacing them. Often not because the thing that is being replaced is actually lacking, but because someone just wants to make a new thing or because they dislike one particular aspect.
Certainly from Google I have seen this attitude (context: The Jujutsu creator is a Google) where they often seem to be more eager to replace things like APIs and sometimes frameworks rather than maintain and expand them. without much of an explanation of why the replacement is actually needed or actually better overall.
As you noted, jj seems to be directly compatible with git, so it is less of an issue here. But git is one of the few things that has been mercifully stable and ubiquitous in the software development world, and has been for almost two decades now. While I don't think stagnation is good, I often do wish that the same was true for other aspects as well.
Sorry, I guess this grew into a bit of ranty tangent. Though the main point as far as I am concerned remains, other than it is something new I seem to be missing a big selling point for jj.
Edit2:
I guess I should expand a bit more, even though this comment is already quite long. I do realize that the article I quoted and linked does move on to say git has many issues and continues listing them. I'd also say that for the majority of people using git these are not actually issues, as most people don't work as intimately with git (or any VSC for that matter) that they need to do so. The basic concept of git that most people likely are working with is not that difficult. In fact, I suspect that the most difficult thing most people ever deal with are merge conflicts.
And at this point I get back to my rant about “things being better because newer and not explaining why”... Because further down the line I came across this remark.
Why though? If you call something bad and unreasonable, then you should give examples for it and not leave your audience guessing what you might mean by it.
I am honestly sick and tired of this sort of abstract arguing in software space. If you can't coherently make an argument as to why something is better, then I am not going to spend the mental effort trying out the “better” thing.
A ranty tangent isn’t so bad in this case. Sure, git has flaws, but they are definitely not bad enough for me to want to switch to anything else. With all the changes we constantly need to deal with, APIs, languages, frameworks, etc. I don’t mind keeping some things the same.
I'll indulge a ranty tangent, given this is directly relevant to my work.
Some good excuses for rewrites:
Git doesn't really suffer from much of those problems, wheras a lot of my work projects do.
It's also why I've never really dabbled in alternative shells, despite using bash constantly. Almost all of the pain points get sanded down smoothly with configs over time, while most of the new features in newer shells/utilities seem mostly cosmetic rather than functional.
New kernels and drivers written in Rust make a lot more sense than rewriting git. You can point to huge numbers of flaws in existing kernels and see tangible improvements.
Not to say it's unreasonable to try, but that if you're hoping to recruit early adopters to help, you need that good pitch, as you stated.
I'm reminded about all of these NoSQL databases, how a big draw was that you didn't need to learn SQL. But as time went on, to fix various flaws in either the engine or the API, huge subsets of SQL (and RDBMs as a whole) ends up getting tacked back on. So now there's hundreds of highly divergent unique APIs instead of fairly-universal SQL that is relatively easily ported between systems.
Nowadays there are things like Cloudstore’s Durable Objects, which have a SQLite database built in. It’s sorta similar to NoSQL since it’s effectively a SQL database per document. Lots of SQL, though.
I’m wondering if something like that versus perhaps Neon’s Postgres hosting would be a better way to scale. For my tiny projects, it doesn’t matter.
https://stevelosh.com/blog/2013/04/git-koans/
While cute, it is also outdated (it is over 10 years old) and very much cherry picked. Not to mention that if these inconsistencies are the biggest issue with git I'd say it is doing darn well.
Some things mentioned there are still not as consistent as they could be, but other things have actually been improved on since then.
Which is actually part of why I am so tired of the "replacing old thing with entirely new thing" because the old thing can often be improved on itself, and often things do improve.
To quickly go over some of the points listed:
git switchhas been introduced as well asgit restoregit branch --show-current. I should also note thatgit statusis also a command that fits in this category and also has been improved over time.The fact that it impossible to distinguish the Git Manpage Generator from the real thing is a good enough illustration of the problem.
Not really though?
Really.
I have actually written a jj "review" of sorts earlier this week, which might explain some of the pull factors for jj. It does sort of assume that people are aware of the push factors for git though.
The tl;dr is basically fewer concepts to manage, more consistent UI (95%), and a nicer experience when working on follow work from stuff that might be revised (e.g. from a code review)
Thanks! I need to go over it in more detail but you manage to make a much better case and better explain the context.
Also, given the linked tutorial and other things I came across I had thought jj to be much more mature.
I guess you linked to lobste.rs because of the discussion there? Anyway, direct link to the tutorial: https://steveklabnik.github.io/jujutsu-tutorial/
Yeah, I wanted anyone interested in the tutorial to see its author's comment about how it isn't 100% up-to-date anymore. I figured linking the discussion instead of the tutorial was easier than writing my own comment about it