For example Firefox could fix it's issues with VSS crashing on GPU's so that Linux distros like Nobara don't have to ditch Firefox as the standard browser in favour of Brave. Granted, that would only get them back a couple of hundred users but hey: marketshare?
For example since firefox doesn't support WebNFC I can't do online shopping because during 3D secure my phone can't recognize my credit card being tapped. I have to use Chrome instead. Frankly, I don't care if WebNFC is "slop" or not. It's solving real world problems.
I've read the Jujutsu documentation and a lot of praises for it, and its most compelling feature is a simpler UI compared to Git. There have been other VCS tools with arguably better UIs and feature sets than Git (Mercurial, Fossil), and yet they haven't gained traction, for better or worse. The only reason jj is having more momentum is because of its compatibility with Git, which was a smart decision by its developers.
A better UI is not something I would consider a next step for a VCS tool. I can do that myself with my shell and small helper tools. Whereas features like semantic and binary diffing would be compelling generational improvements over Git. I know these can technically be tacked on to Git itself, but a VCS built for them would be able to do things Git simply can't. These are just two I can think of, but a next generation tool would be evident without requiring much explanation. Just like DVCSs were over the previous generation of tools.
jj is not just a simpler UI. Its rebase is fundamentally more powerful than git, it has things like the operation log, first class conflicts, etc… that git doesn’t have.
I think a big problem with Git is that it's not opinionated enough. Every team has their own Git flow because Git makes it possible to do so and most developers love nothing more than micro optimizing every minute aspect of any work that is not the task they've been assigned this sprint (myself included), or avoiding learning anything at all (half of my coworkers) thereby leaving the decisions to people like me. I'd much prefer a tool that has one way to do things and everyone just had to "get with the program." Instead, we have this Swiss Army knife that can do anything but requires arcane knowledge of how to do things that are just slightly off the beaten path.
I'm very comfortable with Git and have saved coworkers in just a few minutes from what they thought was going to be missing days of work. But I'd much rather if they had never gotten into that situation or could easily fix it themselves. I don't like the idea of every software team needing a Git expert in easy reach just in case something goes awry.
The problem with an optionated tool that mandated a specific workflow is that people that can't follow this workflow can't use the tool
This follows the Unix principle of "provide mechanisms, not policy" (as I remember from the esr book on Unix philosophy - <imagine a link here>). Git provides mechanisms for version control and it's up to users, projects, organisations, etc to set up policy. That's because mechanisms are more universal, and policy changes with the whims of the stakeholders
(I actually agree that tools that mandate a workflow are more enjoyable. Not everyone needs to use the same version control and different DVCSes can or could be interoperable like git and jj are)
Yeah, I think we could use a little more of "not trying to be everything for everyone". If more opinionated tools meant there were five or ten VCSes in common use rather than 1 or 2, I think that would be a better world.
As long as they are interoperable, sure. Otherwise, network effects tend to the local optimum of a single VCS
Which is why jj is interesting, it managed to find a way to coexist within the Git monoculture rather than swim against the tide like Mercurial, Darcs, Pijul, Fossil
This is a good point, git is more like a very clever toolbox than an actual "version control system". You can certainly implement a vcs using git, but it doesn't exactly start out as one.
If you could make it opinionated in one or two ways, how would you do it? I'm having a hard time thinking about situations that would be solved by this
Actually, the more I think about it, the more I realize the problem is that Git is too opinionated about a bad idea: attempting to make a DAG feel like a linked list in order to make it "easier" to use from the CLI because CLIs make it way too hard to visualize DAGs (don't come at me with your CLI DAG viz. Even the best ones are strictly inferior to the simplest GUI DAG viz).
There are really only two things I care about: the state of the files on disk and the state of the index. And I really only care about where I am and where I want to go, everything else in the middle is noise.
To me, the staging area isn't "real", it's just a tool for working with the other two. Git doesn't need to pitch a hissy fit about editing history. Allowing easy edits of history would obviate the need for the staging area. But because they called it "history", now we have emotional responses to the concept of editing it, like we're somehow committing political revisionism.
But the existence of the staging area and the attempt at making the DAG look linear makes reseting ridiculous. Every time I need to do some kind of reset that isn't --hard, I have to read my Git GUI's descriptions of what each type does, and yet somehow it still doesn't have the combination I actually want half the time. All these named reset types could just be two separate reset commands, both pointing to a commit, one resetting the files on disk, one resetting the index. Sometimes I end up having to do a two step reset of a combination of hard forward then soft backwards to get what I want.
Similarly, all the different merge strategies are dumb. None of them ever do the right thing. I'm always getting stupid shit like new blocks that insert a new ending curly brace after the previous block, followed by the new block body, then the original ending curly brace from the old previous block. Half the time I just use the reset hard/soft to then manually review changes to enact a manual merge rather than trust merge to do anything reasonable.
Sacred history makes it way too hard to organize commits in any logical way. I want my VCS to be a super-powered UNDO. I don't need it to be an audit log of who did what and when (auditability only matters for releases so why do I have to be saddled with it minute by minute?). I basically want to be able to edit two or more commits in a sequence as easily as I currently can edit the staging area, so I can easily guarantee ordering of changes to partially related modules that I'm working on together. C depends on B depends on A. I want to be able to work on all three at the same time, but make sure all changes to A come first, then B, then C, and I want to be able to do this incrementally over the course of the day, rather than all at once when everything is perfect.
But this fetish of not changing history even though we can totally change history biases all other Git tooling to attempt to appear like it operates in linear history. Like how there's the HEAD pointer that can be offset; uuuh, what happens if that offset reaches a fork (I've never tried, the poor DAG experience of the CLI has kept me in GUIs which makes the HEAD pointer completely unnecessary). Or how log is basically unreadable.
Don't even get me started on submodules vs subtrees. I have to get to work.
> All these named reset types could just be two separate reset commands, both pointing to a commit, one resetting the files on disk, one resetting the index.
It sounds to me like you want `git restore -W` and `git restore -S`.
I definitely agree that some people are too fixated on "not changing history". I've never mentally had any problem with this and do it all the time because I think it makes things much clearer and easier. If you're restricted from ever amending or rebasing, I understand why you hate it.
I'm having a hard time understanding the issues you're having with reset and the workflow. It sounds to me like you just need to do something like "commit 'WIP A'/'WIP B'/'WIP C'" and fixup them as desired. Things like https://github.com/sjurba/rebase-editor make it a lot faster to do this. It wouldn't be too hard to make a small script/alias to do something like "modify commit A with <staged>, stashing the rest, rebase B->C on top of A, unstash", and assuming they aren't touching the same lines significantly, it wouldn't conflict much. But this could be way oversimplifying what you want.
Thank you for the many tool links! You seems to know this space well. I have come to pick your brain for more.
I have been searching for a while for good tools to split/regroup diffs in a patch series. hunk.nvim looks interesting. Do you know of similar/competing tools?
I frequently hit a problem where removing a spurious hunk from an old commit causes cascading conflicts in all subsequent commits. Are there tools to propagate hunk removal into the future without the manual conflict-resolution pain?
Not the GP, but I might recommend Jujutsu for that, try it and see. It does the right thing when you resolve commits, and it propagates them to git. However, I'm not sure if it'll work, try it and see.
I can't help with your actual problem but I am incredibly curious about how/why you run into this so frequently you need a tool for it. I feel like in my 15 or whatever years of using git I have basically never wanted to remove a hunk from an old commit or anything similar.
I try to leave a good commit trail in my PRs. These are often _not_ the reality of how the code was written and originally committed, but a rough approximation of the intended steps with the benefit of hindsight.
git absorb works surprisingly well. I was quite skeptical in the beginning, but it really turned into something I used daily (until I switched to jj, where I haven't found a replacement yet). If you use stepwise commits I can really recommend it.
small edit: It seems that jj supports `jj absorb` now as well. Wonderful!
Indeed, though I don't think it can create fixup commits if that's what you're looking for. However, it might work great for that if you pair it with jj-spr: https://github.com/LucioFranco/jj-spr
I am often responsible for landing branches created by colleagues who are less disciplined about their diff cleanliness than me. Very often, attempting to regroup a spurious change from an early commit to a separate "cleanup" commit results in a long conflict hell.
Jujutsu is much better than git, and I've switched to it completely, but I do still use lazygit for one thing: It has better diff viewing, it separates the diffs by file and they look nicer. It's the only thing keeping me on lazygit, as jjui is much better otherwise.
also just to add that I've noticed that `jj` comes way easier and more intuitive to newbies I've mentored. Just yesterday I told a friend to commit his changes and he just wanted to do `git commit` (without remembering to do `git add` first). This made me realize we should just install `jujutsu` for him and he's been committing very diligently afterwards. Can recommend trying this with any people you mentor/teach.
That's also my opinion, that jj should be easier for juniors to pick up. However, I felt like there's a lack of learning material targeted at people without prior VCS experience. That's why I wrote "Jujutsu for everyone": https://jj-for-everyone.github.io/.
just to add to the chorus, I'm switching to jj as well. I haven't started using it in every project but it's only a matter of time I think.
That said, I do which for a more jj aware GUI. For one, it's nice to be able to quickly see diffs across a bunch of changes. I use gg for this but I'd prefer a side-by-side diff and, ATM it only has a traditional diff.
Also, watching the video of git butler, it seems like a jj UI could take a lot of inspiration. I'd love to be able to just drag changes rather than `jj rebase ...` and/or drag selections of lines.
I'd also like a nicer GUI for interactive splitting/rebasing than the TUI UI built into jj
If you give people glasses instead of solo cups, I find that partygoers will tend to treat your house with a lot more care and respect. We have a set of glasses that have little black stickers on them that are a material that works well with chalk, so people can label them.
Yes, there's a risk of breakage & having to clean up, but overall I think it sets a better tone.
I really love the following things that I can do with kitty:
- Access the scrollback buffer in neovim
- Access the last command output in neovim
- Animated cursor trails. It sounds dumb at first but I find that when sharing my screen, the cursor trails help other people keep track of my cursor when using neovim.
Here are my configs to quickly load @screen_scrollback or @last_cmd_output in neovim
Gotta give a shoutout regarding Ghostty [1]. I keep switching terminal apps; I'm on an iTerm2 kick right now… but I used Ghostty for a while and it's pretty damn cool.
Anecdotally, it feels the fastest to me. Also GPU-accelerated and super configurable. It's amazing how a guy (Mitchell Hashimoto)[2] leaves the company he co-founded before it was sold to IBM.
