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.
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.
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.
Good naming is hard, but you don't need those for your use case of potentially discardable work
That way a 1000 line pr consisting of 25 commits can be landed as 5 dependant prs with a much more focused review.
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'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'd bet within the past week you were swearing at git. :-)
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.
I've used CVS, SVN, hg, bzr, and git. Why does git stand alone as the only VCS where devs need so many foot bandages?
A few hours on https://learngitbranching.js.org/ and it'll make sense to you.
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.
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.
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.
Let's stop making excuses for mediocrity.
This is why we have buffer overflows...
In theory, this is not an advantage of the idea of the index, but simply a consequence of the fact that no GUIs have yet been written with jj in mind.
In practice, this can be a real limitation of jj for people who are used to such GUIs, for now.
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.
Yes — I've been using it as a Git replacement for a few months now. A little rough around the edges but mostly it just feels like a better Git to me.
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.
Of course if there is an algorithm at some point, it would be really cool to see it described somewhere.
I can't afford to invest in Google's soon-to-be-abandonware projects.
Jujutsu is a very meaningful and good name for VCS.
By the time I got to the changes section I was a bit too tired to keep reading.
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?
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.
I plan to return to my experiment sometime, would love tips on large repos and making it more manageable.
[1]: https://www.mgaudet.ca/technical/2023/11/23/exploring-jujits...
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.
Detached HEAD and all, it's not that complicated to use.
When you come up with a replacement for javascript, then I'll be interestted...
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.
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.
Maybe it has some support for this already since it apparently works with Google’s internal monorepo? I can’t tell what the story there is.
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
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!
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...
