All these things just remind me how depressing it is that we all use this deeply flawed tool, git, and no one can get enough critical mass for a substantially better version.
the world if filled with "good enough" tools and I don't foresee that ever changing tbh. You'd have to offer something really substantially better than the status quo to gain critical mass. That being said, I think the only thing about git that doesn't make reasonable sense are the damn command line flags and subcommand names. The actual semantics of git are pretty much exactly what you want for source control.
> I have been using the Git backend for the last seven months, full time, on every one of my personal repositories and all the open source projects I have contributed to. With the sole exception of someone watching me while we pair, no one has noticed, because the Git integration is that solid and robust. This interop means that adoption can be very low friction. Any individual can simply run jj git init --git-repo . in a given Git repository, and start doing their work with Jujutsu instead of Git, and all that work gets translated directly into operations on the Git repository.
Well that sounds... pretty good actually! Makes me want to try it too...
Three or four for me. Or, however long since there was a jj introduction posted here that got some traction. The only person on my team who’s even aware is the one other person I converted. The interop is that smooth.
I feel like you and I must have the same taste in technologies. I got into Rails (and Ruby itself) around 2007 then fell in love with Rust around 1.0. Now here I find out you’re a jj convert too!
... I want it to be buck2, but I'm still not quite sure how exactly stuff is shaking out. If the open source prelude was better, I'd use it over Cargo.
Nah, git has lots of bad design choices that are deeper than UI. The index doesn't need to exist. There is a lot of state that is not recorded anywhere - history lost forever. The rebase vs merge disaster. Etc etc.
> git has lots of bad design choices that are deeper than UI. The index doesn't need to exist.
The index is a useful tool. You can opt out with `git commit -a`
> There is a lot of state that is not recorded anywhere
Examples?
> The rebase vs merge disaster
??? How is this a disaster? They serve different purposes and have entirely different semantics. You can use rebase to force fast-forward merges (which do not create merge commits), but I fail to see how this is a disaster.
You cannot "opt out" of the index. It's always sitting there.
$ ls -l .git/index
When it gets corrupt, though, you can blow it away. It gets rebuilt.
The reason it can be casually rebuilt is that there is a copy of it in the HEAD commit.
The git index is an intestinal appendix. It has no reason to exist.
There is no need to "stage" changes and then move them to a commit. What is called staging should just create a new commit.
The index creates duplicity. Many commands operate on both the work tree and index, or separately on either one.
Your working tree can differ from the index, which differs from the HEAD commit, so then you have "git diff" (tree to index), "git diff --cached" (index to HEAD) and "git diff HEAD" (tree to HEAD).
What's the point of staging a commit, when a commit can be amended? You need staging for something that cannot be easily fixed once it is deployed.
To be clear, jj retains the full power of the git index, without having one. To use git terms, the index is just a normal commit like any other. The index is one of my favorite features of git. I don’t miss it in jj.
> Examples?
For one… the index! It’s not part of your history. The working directory can contain dirty state that’s not tracked anywhere. Those are the big two off the top of my head.
> how is this a disaster?
I’m on your side with this one, and jj supports both just fine.
Not a disaster, but merge was not strictly needed. We could've lived with rebase only.
But in git (unlike in jj) rebase is deeply flawed. If you ever needed to resolve the same conflict through several commits you know it. That flawed git implementation is why people kept using merge yo solve the problem on a single final commit.
My main issues with git are all about version control of branches.
Which branches were commits originally created on.
What commit was branch X on 2 weeks in the past?
(My personal biggest issue) -- there is no way to delete a branch in a version-controlled way (that is, let me un-delete it later). 'reflogs' don't count, I want to be able to version-control my branch deletions.
And if people (I'm not accusing you, person I'm replying to, but I get this a lot) say "git isn't for that", well then it's really annoying that git has become "the version control system for everything".
This will sound flippant but it's an honest question: who cares?
I use git all day, every day. Sometimes CLI, sometimes a dedicated UI (e.g. GH desktop but have also used Tower and other dedicated tools), sometimes a UI in something else a la VSCode. I write code every day.
Why should I care at all about rebase vs. merge, whether the internals of git are optimal, whether index needs to exist at all or what it even is?
I think this is sort of what the other comment is getting at about a replacement needing to be much better and that git is good enough. I can count on one hand the number times I've ever needed to glean information out of old commit messages and when something got merged into something else.
Arguing about git workflows and whether you should rebase, merge, squash merge, trunk deployment, gitflow, etc. all seems like ultimate bikeshedding to me. If you're shipping code and making money your git workflow is irrelevant. If your project is so convoluted and broken and you're gaining actual useful information from a 2-year old commit message that you couldn't get just by looking at the code it feels like something else is fundamentally broken that better git internals are not going to address.
I mean, you can use this logic to favor the status quo in any given circumstance. Some people are of course happy with that, but some folks want to try and improve. Not everyone has to care, but not everyone has to not care, either.
I swapped to jj because it’s both easier to use and more powerful than git. To me, anyway. And I was a “you can take git from my cold dead fingers” type person. A “the git cli is fine” type of person.
I would care if a new VCS would make my life easier. This quote from the linked article:
> very few working developers have a good mental model for Git. Instead, they have a handful of commands they have learned over the years: enough to get by, and little more.
...pretty much describes me TBH. I know enough of git to get by day to day, but if I need to do more than that, I have to rely on StackOverflow et al. Which is always frustrating and feels like a waste of time.
I would try a new VCS if it made my life easier too, but I think my point is just that the quote you posted is not only accurate for most developers, but that there's nothing wrong with that. Having a perfect mental model of how git works is going to be a waste of time for anyone who doesn't want to actually work on git itself.
There was a time when a VCS could just be a slightly better VCS and it could probably gain traction.
But now, for both better and worse, git is no longer just an app or a tool, it’s just a fundamental library and protocol that IDE:s, Build systems and project/work management systems build on. It has become almost too late to change.
The semantics of git are “ok”, but mostly it’s just a big leap ahead of cvs and Subversion. As always in any git thread we’ll see people (including me) expressing hope that Pijul will one day be successful enough to break the git monopoly.
> how depressing it is that we all use this deeply flawed tool, git
Maybe a change in perspective can help you be less depressed. I don't find git "deeply flawed"; on the contrary, it's an extremely useful tool with an easy to grasp data model. Some parts of it are quirky, sure, but I find it very easy to use productively in code bases small and large, private or shared.
It's such a huge improvement over what was used before, it can be a little weird for me to hear people complain so hard about git. But hey, some fresher perspective than mine surely exist.
Anyway, instead of thinking of git as deeply flawed, try to see it as a battle tested tool without which your job would suck in ways you can't even imagine.
You're standing on the shoulders of a giant, easily wielding its power, and it sounds like the wart you found on its chin is a huge catastrophe somehow. Find a way to appreciate the giant until a worthy successor inevitably emerges, and maybe things will seem a little less depressing. :)
>Anyway, instead of thinking of git as deeply flawed, try to see it as a battle tested tool without which your job would suck in ways you can't even imagine.
you can start using sapling today. its github compatible and production ready. as long as the new tools support github or whatever forge/hub you are using, there is no need for critical mass for adoption. This is not possisble for radical approaches like pijul, but that approach is not fully proven yet.
Isn't sapling only compatible with git servers and not local repos? That is a huge impediment with so many tools expecting git. That is what i find impressive about jj is it is compatible with local repos.
that is true, i have a separate clone of my repos with sapling and git and use 98% of the time the sapling one with sapling and most importantly interactive smartlog (which is 1000 times better than most git tooling so would be reason alone to do this.) for the few times i need my git tools i sync the git clone via the git remote and then use the git tools on that repo.
Not my experience at all. Most devs I have met in real life love git. It is certainly not perfect but it is good and way better than what came before. I would be happy if someone wrote a replacement which improved substantially upon git but if that never happens that would be fine too.
