Git is too hard

> You really believe that git stores -- in full -- every version of a tracked file?

Yes, it does.

> Every commit that deletes the whitespace from an otherwise empty line in a 30KB file is another 30KB of hard drive space

Yes, it is.

"It's worth repeating that git stores every revision of an object separately in the database, addressed by the SHA checksum of its contents. There is no obvious connection between two versions of a file; that connection is made by following the commit objects and looking at what objects were contained in the relevant trees. Git might thus be expected to consume a fair amount of disk space; unlike many source code management systems, it stores whole files, rather than the differences between revisions. It is, however, quite fast, and disk space is considered to be cheap." -- https://lwn.net/Articles/131657/

One of the insights of the git design was that, nowadays, disk space is cheap. The first releases of git always stored each object separately in its own file in the object database. Git still does so nowadays, but once the number of files gets over a certain threshold, newer releases of git run an "automatic GC" which combines these "loose objects" into a "pack file"; and within that "pack file", it uses a binary diff (a xdelta) between similar objects to reduce the total size. But that's just a physical storage optimization; in the logical model, whenever you ask for an object, you always get its full contents, not a delta against some other object.

For our project, a flow like `create feature branch -> implement -> push -> review -> merge to master` is rarely something that finishes every day (but there are daily changes to master from someone else on the team). Builds are something that happens for every change to master, and there is constant QA on those builds. Even if we chose to release those builds to customers, the question of "did a fix for bug X make it into build Y" would still arise quite often.

An example issue: the interactive `--patch` mode, by far the most powerful paradigm for interacting with diffs, is available for `git stash [push]` but not for `git stash pop`. The CLI is full of inconsistencies of this kind.

I'd say rather 'Version Control is hard'. It should not be that technical.

The very notion of versioning terrified quite a few non-technical but otherwise very proficient office users in my experience trying to sell them the benefits of VCS. Even GitHub or Jira would be considered "for programmers".

On so many occasions I would fail to convince such users to embrace version control in their workflow, even with some Tortoise-like GUIs.

Immediacy of copying their work folder or document and appending a date or "-final" tag to the name is all their busy minds are ready to adopt. And it does make sense, no blame.

This just tells that current concept of Version Control is indeed serving the very specific needs of maintainers, not much the mundane needs of normal users. Thus the complexity of the CLI in the name of flexibility.

My expectation is that Version Control should be mostly transparent to user. It's just some internal housekeeping. On a basic level it's just a Save/Save As operation with very much versatile project-level Undo and Open. MS Office's Track Changes is a familiar workflow for many users, perhaps a similar approach could be adopted for Change Management in broader and less proprietary context.

In Git's parlance, Mr. Version Control is still a plumber that offers users some porcelane sinks, yet user's projects need to live in a whole house with already functioning works and appliances.

I want to believe that Version Control will one day become a basic amenity, not an "exotic" feature that needs constant attention.

Yes! It must have been somewhat controversial to add more “porcelain”, but I’ve loved the recent changes. Restore is a great name.

They’ve also added some guiding comments to various commands (like rebase) that make the CLI more user friendly.

I think checkout was the worst offender, because of how necessary it’s use was for most workflows. Branch could probably use some pruning, too.