The link has a bad title.
The CTO's problem isn't Git. It's the design of the Git CLI commands.
Which, to be frank, I think is pretty reasonable.
Git as a version control system is great, but it desperately needs an "apt style" revamp.
1. The group of people that think git is powerful, but the CLI makes it difficult to do anything that is even slightly outside the box (which, for example, makes fixing a mistake difficult).
2. The group of people that think git is powerful, and the CLI is easy to use, and refuse to acknowledge that it's difficult for some people; rather, they blame the people for being wrong.
I've been using git for 10+ years and I fall into the second group. Every time I get into a situation the isn't the normal workflow, I have to google how to fix it. And I need to check and double check what I'm doing because, if I do it wrong, I need to reclone the entire repo to undo my mistake (and heaven forbid I'm trying to correct something on the origin). I get it, my git skills are not good enough... but by this point they _should_ be, just by using the tool. The fact that they aren't says something bad about the tool.
And that being said, the people in the second group will still say that git is fine, and it must be a problem with me. Admittedly, I'm not perfect, but neither am I incompetent. It shouldn't require a decade plus (and lots of dedicate study) of use to become proficient with a tool.
- There's no group I've seen of that say git isn't powerful
- The group that doesn't want to use a CLI at all doesn't generally participate in this conversation (about the CLI), because they'd rather see a visual tool build on top of it that. (I know a lot of people in this group; I'm not, but I respect where they're coming from)
3 The group of people that think that git is powerful, and that CLI is not the best but still learnable, and that acknowledge that for some inexplicable reasons some people cannot seem to learn git somehow.
I think the problem is that the scope simply grew. Back in my svn days, "merge branch" is something only senior engineer does for entire team and not every day; patches are exchanged by emailing entire files or .patch files; rebase is imposible; you "stash" with "cp file file.old"; and history rewrite is something that happens once or twice in your carrer.
And with git, you are basically expected to do all of that, every day, even if you a just starting.
But the paradigm also is:
- it's made for multiple remote first (e.g: manual syncing is assumed by everything) despite the fact most projects have one
- it forces you to craft your commit index to commit instead of letting you commit all changes by default, and optionally craft things
- rebase exist, and is used a lot
- you have to chose between easy merge and a clean history
- it's hard to get a lock, a big file, a ticket or a todo list in sync in this repo. It's not made for that at all, and requires additional services or apps.
Fossil seems to fix all those.
I will note that at least with GitHub we’ve been using squash merges for a couples years on a pretty large project and it’s solved this for us. The devs that want a clean history (like me the project lead). Bisecting is very easy, every commit references a Jira ticket ticket.
People that want to land multiple patches with multiple messages can make multiple pull requests. If you think the changeset is so distinct that I don’t want it to be one commit in a bisect, each changeset deserves its own review.
As soon as I developed a mental model that pretty closely matched git's everything pretty much clicked. Can't say I've ever got dead-end stuck, though I've made plenty a mess with rebasing, submodules, etc. Now I make temp branches before major operations (or merely save its hash in cmdline comment history) so I don't have to dig through reflog. Another tip, don't use stashes (unless very briefly, e.g. git stash; git pull --rebase; git stash pop), you'll end up with too many of them and forget/lose them.
The other thing I use extensively is the Resolve Conflicts UI of JetBrains IDEs on a 43" monitor to pick/choose edit what the resolution should look like.
Nobody go around moving bits in the internals of the files of git.
What? That doesn't even make any sense. Aside from the CLI I can think of almost half a dozen GUIs off the top of my head. All different interfaces for Git.
I'd say that this is one of the reasons for why many prefer to use either integrations with their IDE, or graphical tools like SourceTree, GitKraken or even something more basic like Git Cola.
Git actually has a page listing other GUI software: https://git-scm.com/downloads/guis it's nice to have many options, some might also like the workflow of TortoiseGit, especially if they've previously used TortoiseSVN
Personally, I also fall into this camp: and if I need to do something "fancy", then it's quite likely that I've diverged from the usual "happy path" too far and should rethink my approach (and if necessary, then just drop down to CLI after some googling). Of course, there are various camps in regards to all of this, but being able to stage/unstage individual code chunks/blocks and spread out/group changes that have already been done in files over multiple commits feels like a nice quality of life improvement. Plus, the diffs that something like the JetBrains IDEs show you, as well as the ability to look at the history for a particular selection is also nice.
Then again, there are also many who don't rebase their branches, or even don't select squashing merge commits in whatever UI they might use (e.g. using GitLab/GitHub for their code review functionality and other features), which some might dislike for any number of reasons. I guess that just shows that there are many different workflows and people flock to whatever they feel comfortable with (or whatever their org/team mandates).
As for the actual CLI, in general there are few programs out there that actually feel good and usable to me, one of which is the Docker CLI (for the most part). I actually compared its discoverability/usability to something like tar previously here: https://news.ycombinator.com/item?id=29339018
Something like Typer actually let's you create your own interfaces like that, though the new formatting is a bit curious: https://typer.tiangolo.com/
That said, I wish we had more TUI software as well, such as https://k9scli.io/ or even https://github.com/bcicen/ctop
Edit: actually one bit of functionality from Git that I miss would be telling it to treat certain changes in the working copy as something that shouldn't show up as modified, but also not even show up as something that can be staged/committed. Maybe something like stash, but whilst keeping the modified files in the working copy.
For example, a local database instance that I have doesn't work with how the app wants to use it (suppose that I cannot fix this for any number of reasons) and therefore I need to change every instance of:
ORDER BY NLSSORT(some_column, 'NLS_SORT = custom_nls_value')
ORDER BY NLSSORT(some_column, 'NLS_SORT = standard_nls_value')
I just need those changes locally so the local database would launch and keep working, but I don't want to have to look at all of these files as "changed" when deciding what to commit. Of course, at that point you might run into some hot water regarding what would happen if the files that contain this value would actually be altered.
My guess of how git would like you to solve this problem would be with a throwaway commit that you then delete with an interactive rebase.
It requires you to keep track of which commits you need to push or remove but it is doable (Actually due to a particular situation I do something very similar at my job)
Which lead into what I think is a critical problem with git: lack of visualization of data; in my opinion git is unusable without a GUI because sometimes you need to juggle a few branches and you need good interactive graphical representations of a lot of the git database.
That's actually a good idea (even if the method feels a bit... contrived), thanks for the advice!