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.
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.