High-Level Problems with Git and How to Fix Them

I find this depressing.

I do think the git model is superior to Mercurial's, by far.

I also find the git commands much, much easier to use than Mercurial's, unless I stop caring about having meaningful commits.

With Mercurial I end up just committing lots of work in one go, with minimal logical splitting, and that's that. The Mercurial repos I share with others are full of useless (to me) merge commits because no one can bother rebasing as rebasing is not as easy on Mercurial.

With git I can spend the effort of making clean, logical commits and rebasing so that no one need see pointless internal-to-my-way-of-working commits. I can do this because git does not hide its internals from me. I know git is a pile of anonymous commits that form trees, with branches and tags as symbolic names that resolve to specific commits in the pile.

See https://news.ycombinator.com/item?id=15910094 in this same thread for more on how the git model is natural.

There's three ways to deal with the git index/staging area:

- always commit everything, merge/push that (Mercurial style)

- always commit everything, then eventually do a rebase where you merge/split commits into logical units

- always git add -e then commit logical units

I do mostly the latter, but since I don't usually write code the way I want it in the end before pushing, I almost always have to go back and rebase to reorder, merge, and/or split commits prior to pushing.

Like you, I'm sympathetic to the idea of "save everything", and I emphatically agree that it's fantastic that you get to save just the changes you want because it allows one to produce minimal and logical commits.

I suspect that the author of TFA does not produce nice, clean, logical, and minimal commits. Instead I bet their upstream is full of merge commits and the merged branches are full of huge commits with lots of unrelated changes, and/or full of "fix a typo" commits that should never appear in upstream histories.

Using a VCS effectively to create clean, useful history upstream is hard, and some VCSes make it harder than others. Mercurial (and Fossil, and...) make it supremely difficult. Git makes it easy (though one does have a bit of a learning curve to get there).

Ironically, all the Merkle hash tree VCSes are git-like under the covers: there's a bag of commits, and some sort of branch name resolution. "Heavy-duty branches", like Mercurial's, are extremely confusing -- I never know how to recover from having multiple tips, and I don't even understand why that's at all possible. Whereas "light-weight" branching (like Mercurial's bookmarks, which still aren't reliable, or like git's branches, which are) is much much simpler -- even Mercurial's community gets this, though they still shy away from light-weight branches for some reason that I still don't understand. Fossil is exactly like git under the covers, except far, FAR superior to git in that it's relational -- Fossil is easily the best VCS ever in terms of implementation. But Fossil's dogma is highly opinionated and Mercurial-like: it has light-weight branches, but the UI is merge-happy like Mercurial's, and there's no rebasing (there's basic cherry-picking functionality, which of course is always the basis of rebasing, but that's it).

I really don't want a Merkle hash tree VCS to hide its tree nature from me.

The staging area is trivial to use effectively.

Just:

- edit files - git add -e - optionally git diff --staged (to review what will go in a commit) - optionally lather, rinse, repeat as needed - git commit

Alternatively:

- edit files - git add - git commit - lather, rinse, repeat - git rebase -i origin/master (or whatever) and reorder/squash/edit/split commits as needed

For the latter's last step, sometimes the easiest thing to do is to squash all commits when you're done, then git reset HEAD^, then apply the git add -e && git commit loop in order to break up your work into logical commits.

When done, push.

My instinctive response is to explain why git is easier. TFA is very unfortunate. I think the author is missing out on a better experience, and their git hate isn't helping them.

That successor ought to be Fossil, by all rights. What keeps me from using Fossil is its opinionated UI.

Lots of people hate git's UI, but it let's you do all sorts of workflows. You can rebase a lot, or merge a lot, or both. With Fossil you're pretty much stuck with a merge workflow.

What makes Fossil superior to all other VCSes is that internally it is a Merkle hash tree organized relationally, with an internal SQL interface. This makes a) development of tools much easier than for any other VCS, b) much easier to write new kinds of queries and make them perform well.

Perhaps some other VCS will come along that will do what Fossil does, but with a less opinionated UI.

I understand why Fossil is opinionated: it's not meant to be a VCS to take over the world, but instead just a VCS for SQLite3 and related projects. As such its developers don't really care for any functionality that they themselves don't care for, and thus my need for rebasing, and a staging area / index, is as nothing to them. I can't blame them, really, but it would be truly fantastic if we could support rebase workflows with Fossil.

Another thing I don't like about Fossil is its approach to repo sync. I like that with git I can push/fetch individual branches/tags, some of them, or all of them. With Fossil you don't get much choice, as it's all public branches or nothing.

Power users (and I'm not saying here that Fossil's aren't) need more UI power. To appeal more widely, a VCS as to support more power users.