I can't stand Git. The points the author makes in the intro are true. Developers learn just enough Git to do their jobs, which is unfortunately more Git than they actually understand. I'm including myself in this. I've been using Git for nearly 20 years (since the very beginning), and I still can't accomplish anything more than the most basic things without reading documentation and hitting up the net for help. Even if I stick with simple operations, I can get in over my head. WTF is "detached HEAD"? I've looked it up dozens of times, and as soon as I get past whatever I'm working on, I forget what it means. I don't know what the reflog is, other than that it has to do with some dark internals. Resolving merge conflicts during a rebase is a clusterfuck. And on any team I've ever worked on, the branch history is a nightmare to look at.
So I clicked on this link with the hope that it might be a kinder, simpler VCS. Especially after the article author talked about how bad Git's CLI is and how much better Jujutsu's is. But it looks like it's just as much of an overcomplicated clusterfuck, and since it's built on top of Git, you still get to experience all the pain of Git if anything goes wrong. And I wonder what kind of frightening scenario occurs when some contributors use Jujutsu and some use Git.
I understand that Git is powerful, and many of its features are valuable for large teams working on enormous projects (like the Linux kernel it was invented to manage). Hardly anyone needs that, though. I want a dead simple VCS for small project use that doesn't come with so many footguns. I know simpler VCS exists, but without wide adoption, GitHub-like repos, and tooling support, using Git is still the path of least resistance.
> WTF is "detached HEAD"? I've looked it up dozens of times, and as soon as I get past whatever I'm working on, I forget what it means. I don't know what the reflog is, other than that it has to do with some dark internals.
I could answer, but I don't think you're actually asking for someone to explain it to you.
I did want to offer a different opinion though. I like detached heads, they are unnamed branches, the first thing I do when working on something new is make a detached head and get to work, making commits, etc, if I decide the work is worth keeping, then I will name the branch. As some smart people have said, naming things is hard, I don't want to name a branch before I'm sure what it is or that I'm going to keep it. Having a bunch of commits that are not part of a branch might sound risky, but not if you understand that commits are never deleted (unless there 90 days old or more) and the reflog and other tools allow you to find commits you thought might be lost. Git does not lose commits, not ever.
Naming is only hard if the names are permanent (cough fossil & hg)
But git names are not permanent, so just use whatever helps you remember: "just-ate-tuna-sandwich", "fifth-time-is-a-charm", "john-is-late", "idea-from-restroom", even "temp123"...
You can always rename to something that makes sense later.
Yup, my names break up into two categories, each with a namespace: `wip/` and `deadend/`. deadend is my personal favorite. Every time I write some code that turns out to not work, instead of spamming undo until I get to a known good state, I do:
git commit -am “Dead-end: I tried doing X but that didn’t work out”
git branch deadend/tried-doing-x
git reset —-hard HEAD^
I like this because, fully half the time I end up needing to draw some elements from that dead-end if it turns out later to have seeds of the right approach in it.
`git branch <something-temporary>` is an absolutely fantastic workflow IMO, combined with committing early-and-often, it helps me decide on logical names for various snapshots of where I was when trying to solve a problem. When I hear people say “squashing is wrong” I can never understand what they’re on about: being able to make temporary semi-meaningful commits and branches on your way to the right answer to a problem, is an absolute godsend.
Yeah, not really looking for an answer. I have a decent idea, and I could guess. It's one of those things where when I find myself in that state, it means I messed something up. I google, read a few sentences, remember what it means and how to get to the state I want to be, and then move on with my life without committing the details to memory. It's one example of the confusing scenarios I find myself in with Git with more frequency than seems necessary. I'd rather debug a Kubernetes cluster.
Git does make a detached head sound like something is broken, but it's really just a nameless branch. Nothing broken about it. Any commits might become hidden, as all commits not in a branch are, but that's only after you move off the headless branch and git warns loudly about this.
I just tested to see what happens if you don't name a branch before leaving it. Surprisingly, despite all that scary looking text about detached head, if you switch over to another branch git will print out a message that you're leaving commits on an unnamed branch as well as instructions on how to get back and name it later (and of course the commit hash can also be recovered from the reflog).
So yeah not only is the detached head state not a broken state, it's not even really a scary state to be in.
For someone who understands git, it certainly is not. But if you are not aware of how git works, committing things when HEAD is detached could to confusion in the best case, and lost commits in the worst.
I just use stacked branches and work out of the top branch. When changes are solid -ish I move down a level in the stack and cherry pick isolated changes into small/focused commits. Then I put the entire stack in review with a doubly linked list references so the reviwer can walk up and down the stack to see the corpus of changes.
That way a 1000 line pr consisting of 25 commits can be landed as 5 dependant prs with a much more focused review.
Why many developers are struggling is beyond me, and so much git-hate, too. It is a powerful tool, but you can get started and a long time (or forever) around with few commands to accomplish your companies workflow - takes half an hour to learn these and put them in your notebook. If you struggle with git, how do you do with your programming language, IDE, debugger? All are vastly more complex.
Imo it is some internal objection (due to hate? laziness?) to deal with it.
Yes, the UI is not intuitive in all parts and partly ugly or from some viewpoints inconsistent, but that lately improved much. Nevertheless, complex is different. Much more effort went into mastering chosen shell, much more unintuitive is the IDE I have to use.. but those are tools, and that's my job.
> WTF is "detached HEAD"? I've looked it up dozens of times, and as soon as I get past whatever I'm working on, I forget what it means.
Don't wanna be mean, but again I wonder how you learn and handle e.g. complex data structures (vs that super simple thing..) or other hard problems in whatever you do.
> And on any team I've ever worked on, the branch history is a nightmare to look at.
Because teams have many people that don't care. I like git, shuffle commits around, rebase easily, conflicts are easy to resolve (there are merge tools that exist to help on top?) or would be hard with any other tool the same? (need to try jj). At least I have seen same shit happen with cvs, svn and also the short time I used hg - people are always at fight with their version control, I don't know why.
I'm glad if there is a new tool that finally solves this, buut, I doubt it ;) Let's see.
> I want a dead simple VCS for small project use that doesn't come with so many footguns. I know simpler VCS exists, but without wide
Sorry, but lame excuse, just chose and try one and see, don't spread that much git-hate if you have not even tried, and mastered, another one? (And here you are with jj!)
I'm frankly embarrassed at my lack of Git mastery. I'm sure I could master it. And considering it's a tool that's integral to my daily work, it's kind of ridiculous that I'm not more comfortable with it.
I've written parsers and compilers, worked on image processing software for the NASA Mars rovers, managed global Kubernetes deployments for Fortune 500 companies, wrote trading desk software used on the NYSE trading floor, etc. Point being, I've worked on some seriously complex software. I'm 100% sure I could write Git itself without any trouble whatsoever (assuming I learned how it worked first).
I find Git to be unintuitive and overly-complex, and to use terminology that isn't obvious. You're probably right about it being an internal objection, but I assure you it's not due to laziness or an inability to deal with complexity. I'm not planning to use jj, because it's just Git with more complexity layered on top, despite their claims to the contrary.
Despite my dislike of Git, I'm still the go-to person for Git issues on the teams I manage. I can fix problems that arise and help others do things right. I still don't like it, and for whatever reason, the edge case scenarios don't stick in my memory.
i wonder where that comes from. i don't even have a fraction of the experience you have, yet i seem to be just fine with git. not an expert, but not having any trouble with it either, and also the go-to person for git pretty much anywhere i work. and i do like it!
is it my age? (i learned working with computers in the late 80s.)
the fact that i first had to work with CVS and subversion?
that i was an early adopter? (i was the first to use git at my job at the time, thanks to its good subversion integration)
have i just not seen how much better git could be? (am i happy with git out of lack of experience with better tools?)
or am i just different? (i seem to have no problem with weird programming languages or frameworks either (although there was this one perl job where i did struggle and ultimately had to give up because i had no help))
To emphasize just one thing in Git that is a source of constant user woes: if you're doing a rebase merge, --ours and --theirs are reversed. This is unintuitive without a deeper understanding of how rebase works, and rebase itself is a concept that is confusing to most users. Conflicts are never easy to resolve under the best circumstances. You shouldn't have to flip everything around just because you're doing a rebase merge instead of a regular merge. I can't tell you how many times I've had to help people with that. Maybe you think that makes total sense and is obvious, but the majority of devs I've worked with struggle with it. The fact that there are different types of merges is already confusing enough. Even the > and < symbols are reversed during a rebase merge, such that even if you know, your brain is twisting itself in knots because of the conflicting visual indicator.
I’m a native english speaker and I view “hate” and “can’t stand” as being synonyms. I can’t for the life of me draw a distinction between what either phrase means.
FWIW I thought "hate" and wrote "can't stand" because I intentionally wanted to tone it down just a little bit. "Hate" is a pretty biting word and I'm trying to use it less hyperbolically. The distinction is more one of politeness than anything in this case, so I agree with you.
> I don't know what the reflog is, other than that it has to do with some dark internals.
I think this illustrates a bit the tragedy of git's (lack of) UI. Since the reflog is a feature, not an exposed hidden internal. It's simply a log of what a reference, say HEAD, or a branch, has pointed at. It's meant to help you figure out what happened, or get back to a place you lost through some other operation.
if you are satisfied with CVS/SVN version - any commit is final and there is no way to undo or modify them - then you don't need reflog. If you mess up, you just say: "oh well this sucks" and leave commit in place. This is what I was doing back when I used SVN and CVS.
hg has similar thing but it's different for each command. For example to undo "hg strip" you manually dig into .hg/strip-backups directory.. I never understand why people call it more intuitive.
That analogy is verging on dishonest. A word processor’s undo button is typically used in service of the operator’s thought process, as it pertains to their actual output, not how they’re using the word processor. The analogue to this is git itself.
I said typically though. We all know the “you move an image in Word and your layout completely changes” meme. Sometimes someone wants to undo something because the tool didn’t do what they intended. Even though I have no empirical basis beyond my no experience, I am incredibly confident that the typical use of Undo in a word processor is because the operator has changed their mind about what they want their output to be, rather than because they had already concluded what they want the end result to be and they just can’t get the software to do it. I have to imagine that you agree with this.
So yes, be thankful that git has reflog. All other things equal, git with reflog is better than git without. I don’t see how your analogy invalidates or refutes the the critique that typical use of git’s reflog is as a result of the operator not knowing how to use git. And to simply say “you’re holding it wrong”, when ‘holding’ git routinely involves standing due East at the next full moon, is absurd.
A person who isn’t “good at” word processors will use it both when they change their mind and when the program doesn’t do what they want (e.g. I didn’t realize that I had a text selection before I started typing and now my selected text is deleted). It’s the same with git, and now we are just arguing about what’s “typical”. An example of when I change my mind about what I told the program to do, maybe when rebasing I decide my merge resolution wasn’t actually what I wanted. That is certainly in the “user changed their mind” class of error.
I’m not saying git has a great user interface that users intuitively grok and rarely make mistakes in. But I am saying that having an undo button is not an admission of that, either.
Because we insist on telling people to Rebase as part of the standard workflow, which is just a huge footgun for people who dont understand what they are doing.
Maybe version control is actually a hard problem, and there are no simple solutions. And I'm sorry to pile on, but if you haven't learned more than the basics in 20 years, have you considered sitting down and doing some focused git work? Maybe play with libgit2 and learn the internals.
Yeah I've just given up on git. There should not be as many interfaces and experts on such a little tool. Now I only use commits and reverts. Not even branches. And all 100% with a GUI. Otherwise it takes up way too much of your attention
But how often do you really need more than the basics? I think you're probably doing something wrong if you constantly need to look up docs on it. If you're not constantly doing that, it sounds pretty good. Takes care of the basics and the more complicated features stay out of the way.
> So I clicked on this link with the hope that it might be a kinder, simpler VCS.
Last thing we want is a kinder, simpler, dumber VCS replacing git, like microframeworks which hardly have HTTP routing and middleware replaced full featured frameworks.
The very comment you’re cherry-picking from right now doesn’t pose a complete git replacement. It’s posing a replacement for git in certain situations.
The issue with people learning git is they learn all this construction around it without actually learning what it is. Branches aren’t real, it’s just a series of commits in time. Like a blockchain, the sha’s must match the previous (that forms the line/branch/tree/root/wtf ever). A HEAD is the end of that line. A detached head is when you have checked out a sha that isn’t the end. Once you throw out the concepts of branches and things, that they are just labels, like tags, moments in time with a previous moment in time. HEAD~1 goes back one node from the head, HEAD~5 will go back 5. You see? It’s easy, it’s simple, it’s not hard. You can revert, you can —amend, you can even stash your changes
> A HEAD is the end of that line. A detached head is when you have checked out a sha that isn’t the end.
This isn’t quite a right. I hope my clarification is helpful!
HEAD is the ref that you currently have checked out. This could be a commit ID, a branch ID, etc., and there may be multiple refs that point to the same commit.
When you check out a commit ID directly, you’re in a “detached HEAD” state because you aren’t on a branch. This is noteworthy because it means that any commits you make will be untracked by any branch, and will only be available in the reflog.
Trying to keep it simple for folks. Yes, we are talking about local - checked out code - head is the marker for knowing where you are. On tree or off. A git reset —hard head will bring you back to that end-of-line for that branch of the tree. I’m not going to go into multi-headed merges.
In the article, it's pointing out that the go-to advice when someone's struggling with tech is often "you need to understand how it works." But honestly, having to know the ins and outs just to use something isn't really practical.
I mean, I personally geek out over the details, but let's be real: most folks, especially those not in software development, don't work like that. Even for us developers, you don't need to know the nitty-gritty of machine code to whip up some Python scripts. Sure, some of us love diving into that stuff, but it definitely shouldn't be a must.
Except these are _developers_, people who are, ostensibly, computer experts. Yes, computers are hard! And version control is a hard problem. I don't expect grandma to learn git, but nobody suggested otherwise. If we can't expect software developers to learn their basic tools, then I really don't know where we go from here.
Do you expect that everyone who uses a database should know all the internals of the data structures stored on disk, journals, ram cache, etc. before they try to do basic SQL? That’s the comparison you’re making: anyone who can’t write a database engine from scratch is mediocre and therefore is lazy.
P.S.
> “developers_, people who are, ostensibly, computer experts”
It’s laughable to me that people have this impression. It’s extremely rare to find a developer who has any knowledge at all on how to do basic computer things like installing an operating system, troubleshooting a network, understanding DNS, or being able to do anything outside of their programming environment.
Before they try to do basic SQL, no. If their job involves writing SQL every week? Yes, of course I expect them to learn how databases work rather than forever treating it as a black box.
> Do you expect that everyone who uses a database should know all the internals of the data structures stored on disk, journals, ram cache, etc. before they try to do basic SQL?
Honestly? Yes. Knowing the basic data structures stored on disk helps you understand why having an index is important, and just creating tables and doing queries on them is going to lead to extremely slow queries. Understanding journals helps you understand transaction isolation levels, which helps you understand why you can’t just have N web workers all doing write queries at the same time and they don’t necessarily see each other’s writes right away if they haven’t committed a transaction. RAM cache helps you understand why journaling is important in the first place if the database crashes.
I absolutely do believe that anyone who calls themselves a professional should be armed with such understanding before they go writing SQL code in a production context. Playing with it as a toy in your spare time? Go nuts, learn in any order you want. But if you’re writing code for an app that we’re shipping to users and that your coworkers’ livelihood depends on, you should get the friggin’ basics down.
> It’s laughable to me that people have this impression. It’s extremely rare to find a developer who has any knowledge at all on how to do basic computer things like installing an operating system, troubleshooting a network, understanding DNS, or being able to do anything outside of their programming environment.
I agree with you, but I would frame this as a lament. It really fucking sucks that my coworkers sometimes show now desire whatsoever to understand why their code doesn’t work on a machine with IPv6 enabled. Or don’t bother to care about why their ABI-breaking change caused missing symbol errors when downstream clients tried to run against the new build. You want my opinion? These people should leave the industry, and we’d be better off.
There’s a difference between a developer and an engineer. I think this thread shows that divide pretty well already. Web Developer? I don’t expect you to be an expert. Software Engineer? You better believe I expect it.
I love 'jj'. I would easily bet on it if I could. I know it's HN and the criticism is almost a badge of honor, but I really hope people try it out.
I also use `jj` without anyone else knowing. I get to smile a relieved smile when coworkers talk about making mistakes with git rebase/reset -f/stash. I don't sweat stacked patch sets. I never, ever, ever lose work. Ever. Never. Not even in my worst fat-finger, because of the oplog.
It's really good. Please form your own opinion from trying it. I also find the article a bit too lengthy to easily digest.
Lots to digest here! I have been keeping an eye on Pijul so it is cool to see some of its features implemented in jj. Sapling[0], similarly, is a new VCS tool out there which can work with a git repo. It also has anonymous branches, no staging area, supports stacked commits and can track the history of a commit over time. I've been using a similar workflow to the article's author: git with a UI to handle commits of hunks of a file to group related changes. My working branch often has unrelated changes that get tossed from branch to branch as I am able to commit. I haven't figured out where these new tools fit into my workflow yet, but I am glad there's new options that will help making working on a project more flexible and organized.
I really liked using Sapling internally at Meta (they call it hg/mercurial internally, lots of people don't even know it's not actually hg under the hood).
Is the publicly available version of Sapling usable? I really miss stacked diffs every time I'm working on a GitHub project. Last I checked it seemed there were some dependencies on Mononoke and EdenFS which are not open source.
To be honest, git is really close to perfect, except for the interface, which is horrendous. I don't think, personally, there's a pressing need for something substantially different.
I'd imagine a binary that replaces git commands with other, saner ones, will do 95% of the work, while retaining compatibility with both past repos and the whole world wanting to use git.
None of pijul's feature have been implemented in Jujutsu. No change commutativity, no associativity, no actual modelling of conflicts. Jujutsu is a better `git rerere`: a good heuristic, but not an algorithm.
Of course if there is an algorithm at some point, it would be really cool to see it described somewhere.
You had me until the part with the log. You didn't show the log, you simply explained how the jj log is confusing and not intuitive at first, and then there was a dive into some functional topics and an explanation of syntax (all while we haven't seen the log) and some more shitting on git.
By the time I got to the changes section I was a bit too tired to keep reading.
This is a fair criticism. I struggled with how to organize that section and I might go back and add an example of what I meant, or even pull that phrase out (it’s actually from a much earlier version of the piece when it was more experience report and less introduction to the tool). I also debated about showing various bits of log output for exactly this reason, but decided not to since there are multiple examples of it in the asciinema recordings. Also, “a bit too tired to keep reading” is indicative of the other reason: this is already a mammoth piece of writing to work through! There is room to deep dive on any of the pieces as their own standalone pieces, too, but at some point I just had to publish the dang thing.
Something that would have been really helpful to me: If the big pitch is "how easy it is" and "the mental model", get to that part sooner! Put up some pictures of what I'm supposed to visualize when I'm dealing with merge conflicts, and the simple commands mapping easily to that mental model.
I also read a ton of paragraphs excited about an easier Git, but I just couldn't understand what you were talking about and how it make my life easier. What does it mean to make merge conflicts first class?
Complains about Git's tag/branches difference is a high chance author left Mercurial boat before they made proper branches.
BTW jj's documentation does a better job explaining what's the revs and changes are.
My only grudge with jj's CLI it uses `-r` to specify first class entities. Git here does rare proper thing and uses positional args for commits and ranges.
Jujutsu is not a Google product. Jujutsu is not a fork of anything, so upstreaming it does not make sense. It does support git repos, but that is a mandatory feature for new version control software to compete with git as people don't want a VCS that is not compatible with one's existing repos. It doesn't mean it's a fork of git.
I'm surprised to see an alternative git frontend that doesn't immediately drop the index for being "too complicated", which in turn makes me drop the alternative git frontend for being "too simplistic". I might try this one out.
jj did drop the index. What appeal do you see in git's index? All it's ever done for me is slow me down by needing to do extra commands / arguments which I sometimes forget.
Based on the description in the article, it does the equivalent of `git add`ing every change by default, but allows you to choose a subset of those changes to be in the actual commit. So the net effect is the same as if nothing was `git add`ed by default and I ran `git add -p` to choose the subset of changes to be in the actual commit, which is what I use the index for.
It's not the same. With git you are doing 2 operations, adding some changes to the index and then commiting. With jujutsu you do 1 operation, splitting a commit. Yes, the end result is the same, but since git has the concept of the index, it requires an extra step and is more complex to understand.
You guys are just discussing different points. OP comment was about being something like index functionality being available at all in a vcs (or git frontend). Yours is about how working with that index functionality is a one step operation while with git it is two (add + commit).
I happen two think that two steps are better. If every new and changed file is automatically included in the next commit this will just lead to more devs not caring about properly splitting up changes into logical and related commits. Just commit everything in a single commit, push, home time! For those people the two step process seems a needless waste. For me it's to encourage devs to only add related changes into a single commit.
The original comment was "drop the index for being "too complicated"". Having to go from "working tree -> index -> committed". In comparison Mercurial only has working "tree -> committed" and Jujutsu only has "committed". The idea of dropping the index is to avoid having extra states changes must pass through. Technically Jujutsu still has the index, as it uses libgit, but the concept isn't exposed to the end user.
>this will just lead to more devs not caring about properly splitting up changes
I strongly disagree. jj split reduces the friction in splitting commits. Just think what you have to do to split a commit with git following your 2 step guidance. git reset HEAD~ && git add -p commit && git add -A && git commit. It's even worse for jj split -r @-- (split the 2nd to last commit (ignoring your working commit)). For git you have to do git rebase -i HEAD~2 && git add -p commit && git add -A && git commit && git rebase --continue. In the interactive rebase ui you select the 2nd to last commit to be edited. People avoid splitting with git because there is too much friction. It takes too many commands. It's hard to remember. You can screw up and waste even more time. If you want to encourage devs to split up commits then make it easy to do.
>The original comment was "drop the index for being "too complicated"".
Correct. Lots of alternative git frontends drop the index and force you to include all changes in the commit, because they think users find the concept of staged vs unstaged changes confusing. This one doesn't.
That isn't accurate. Jujutsu doesn't even let you have untracked, working, or staged changes as everything is always committed (except for what's in .gitignore). Any change you make will be forced to be part of your current commit.
I never said anything about splitting a commit. My entire point was about creating commits from current changes, either with or without the index. And how I prefer the git way that is two steps because of the index, so it's more helpful to commit what is related instead of everything at once. But it's okay, sometimes we misunderstand.
Jujutsu is the topic of this comment section and in Jujutsu all changes are always part of a commit, so splitting commits is the only way to separate changes into their own commits. And yes, with git I have wanted to retroactively split commits apart too. I don't always get everything perfect on the first try and may want to move certain changes from one commit to another.
I love the ideas of jj but `jj split` is just an awful workflow. Splitting commits is too important of a feature to get right and jj gets it really wrong.
I initially thought the same but have come around. The problem at this point is the lack of tooling that understands and supports it. You could, quite reasonably, say they should have made a different choice based on what works best with tooling today, and that would be fair; but I think that would leave us in a bit of a local maximum. My hope is that if and as it catches on, tools will grow feature and modes to work with it—just like they did to work with Git’s index.
I haven’t tried jj yet, but from my reading of the article, 80% of the problem is that jj split is backwards for some (most?) uses. You seem to want to split a change such that the newly split piece goes before the part you leave alone, and jj split wants to do the opposite.
Certainly when I split a change up in git or hg, I’m usually trying to break off a piece that goes before the rest. TortoiseHG’s committer works like that — you select the parts to commit, and the rest stays uncommitted in the working copy.
So maybe the only tooling needed to make jj better is a mode (or maybe a default) that reverses the initial guess as to which parts of the change go where.
Might have been a lack of clarity on my part. When you split, you are actually choosing "what goes first". The issue workflow-wise today is primarily a lack of tooling designed to represent this process visually in an easy way.
If I understood correctly, the problem is that the default is that everything “goes first” and you have to remove the hunks you want to go second. As if in a Git tool everything defaulted to “staged” and you had to click “unstage” on what you want to go second, which is the reverse of what they all do.
Except…when you’re actually splitting an existing commit with interactive rebase, don’t Git tools make you unstage changes that should go second? I see how it’s backwards and annoying compared to “git add -p” for a new commit, but they seem equally bad for splitting existing ones.
In “REVISIONS AND REVSETS”, you say “Revisions are the fundamental elements of changes in Jujutsu, not “commits” as in Git. But then you proceed to use “revision” and “commit” apparently interchangeably, and you don’t explain whether there is a difference.
You also lost me a bit on “change”. What is a change? If I modify a change, does it keep the same id? What if I send you a change and then modify it? At what point are changes immutable? What if I end up with two changes with the same id that aren’t the same change in my repo? The asciinema casts might have helped a bit, but the lack of scrolling or an easy scrubber makes it really hard to follow.
I keep hearing things about jj being excellent, but haven't actually tried it. My brain is very git wired at this point, but when you keep hearing good things...
The first couple weeks there was definitely some friction, especially because having the working copy be a commit itself takes some real getting used to. Once I got over that and learned that I did not need to name every branch and could just work away and name branches only for pushing to Git remotes, the switch flipped very hard the other way. Git feels awful now.
I have to say, I really like that it claims to work in an async fashion with rsync/dropbox not interfering with the repo. But my brain is also wired hard on top of git.
This looks interesting, and I will try it out, but I don't feel any friction using git directly. The only exception is rebasing in some situations can be very annoying, and git LFS. How does JJ deal with submodules, subtrees, and LFS objects?
"Maybe the little bit of extra friction when you do want to push a branch is worth it for all the times you do not have to consciously move a branch backwards to avoid pushing changes you are not yet ready to share."
Very True.
This whole article really makes me miss mercurial. No need to create branches all the time, very rarely needing rebase -i, revsets, simple commands, those were the days! I'm almost afraid to give jj a try because I'll fall in love and probably lose it again and have to go back to git
Ironically, it says that the problem with git is you have to internalise it's model to use it effectively. But then describes JJ in terms of how it relates to what git does.
Talks about how it uses revisions not commits or something, but never really explains why it's good, just more that it's different to git.
So I think this is probably a very good article for someone who actually knows git, but isn't very good for the users he says would most benefit from it!
Interesting discussion about `jj split` and how it opens up a GUI tool to select what changes you want to pick.
I'm using `git gui` a lot, I think about everydays, to pick up exact what I want to commit or amend my current work. It's not a very fancy tool, but it ships with git by default and I feel it's really underused and could actually make people's life easier for editing undergoing work...
Git bisect, reflog useful but really a pain to use on the command line. There should be a GUI first class citizen for next gen source repos. You build the gui for every command you add.
neovim and vim (since v8.1) come with a terminal mode, and the default key combinations to get out of terminal mode is a little cumbersome (<C-\><C-n>). It's not unthinkable that if someone already maps jj to get out insert mode that they would do the same for terminal mode.
So I clicked on this link with the hope that it might be a kinder, simpler VCS. Especially after the article author talked about how bad Git's CLI is and how much better Jujutsu's is. But it looks like it's just as much of an overcomplicated clusterfuck, and since it's built on top of Git, you still get to experience all the pain of Git if anything goes wrong. And I wonder what kind of frightening scenario occurs when some contributors use Jujutsu and some use Git.
I understand that Git is powerful, and many of its features are valuable for large teams working on enormous projects (like the Linux kernel it was invented to manage). Hardly anyone needs that, though. I want a dead simple VCS for small project use that doesn't come with so many footguns. I know simpler VCS exists, but without wide adoption, GitHub-like repos, and tooling support, using Git is still the path of least resistance.