High-Level Problems with Git and How to Fix Them

No. That would be like handing a professional compound bow [0] to a newbie instead of a simple one [1]. The note "only as complicated as you make it" would be quite sarcastic in this case.

[0] https://outdoorsexperienceonline.files.wordpress.com/2013/07... [1] https://www.archery360.com/wp-content/uploads/2016/05/tradit...

While many of these criticisms are valid, they seem to be written from the point of view of a user that doesn't really want control over their versions, they just want versions.

I'd suggest that there are other tools for this, such as a properly configured ZFS setup which are atomic beyond most users widest dreams (especially if all the versions of a vim .swp file are retained).

If you just want versions, yes, git gets in your way, because git is about control. Yes if you have all those versions you could go back and 'squash' them into a commit, but can you imagine trying to bisect those to find a bug?!

Somehow I also get the feeling that this perspective is similar to that of a friend who really didn't like the idea of pulling, and that he should just be able to push to the remote repository. A seeming lack of awareness of the collaborative side of version control and development.

Git isn't just about control, it is also about providing additional provenance information and context needed in order to understand what code does and the reasons why changes were made. Sometimes in order to get there we have a bunch of low intention commits that we use to checkpoint, and let's be honest, how many have created commits that put a tree in a broken state? I know I have.

The bit about making the documentation more consistent in its use of vocabulary seems like something that will have a couple of pull requests by the morning.

tl;dr If you want versions use ZFS if you want control and communication use git. Talking defaults is always a good exercise. with and EDIT: show work would be amazing ...

edit2: I just don't see the workspaces model passing the bag of dicks test. I want to code, I don't want to have to become a community moderator and clean up people committing all sorts of crap to my project and on the other side I just wan't to code and not have to deal with the bags of dicks who are going to gate keep their projects. There are just too many social edge cases and the differences are mostly just semantic (iirc the way github implements forks is basically as workspaces anyway...). That said, I would really like it to be possible to have pull requests be part of the repo history instead of, say, the listserv.

Some useful commands I'd use in scenarios like this are:

  git add -p # select what to add to the staging area
  git reset -p # deselect chunks that I decided I don't want anymore
  git stash # saves your working state in a temporary commit (not in your branch)
  git stash pop # restores the working state from the last git stash command and drops the temporary commit
  git rebase -i $start_point # where $start_point is either a branch or some commit in your branch history. -i means interactive, which allows you to reorder/edit/reword/squash commits
  git checkout -b $newbranch $start_point # you can make a new branch at any commit in history, so if you decide to reorder your commits, then declare and older commit as a branch and get it merged first, that's fine. $start_point is optional, if unspecified the current HEAD commit is used.

For your specific example, with a staged partial commit on branch idea-1, I would:

  git commit -m 'WIP idea 1'
  git checkout -b idea-2 HEAD~1 # makes a new branch at the parent of the HEAD commit
  git add -p # pull in the desired changes
  git commit -m 'idea2 implementation'
  git checkout idea-1
  git add -p # stage the rest of the changes
  git commit --amend
  git rebase idea2 # if idea 1 depends on idea 2

I do wish git had some notion of sub-commits with their own messages, and a better UX for cleaning up a set of commits before merging them.

you can --keep-index to avoid stashing it, and then make an additional stash. If you have modifications within the same file it'll complain about conflicts though, so on the second sash you'll have to `git stash show -p | git apply -R` and then drop the stash, which is super clunky.

`rebase` is simpler than `merge` in larger teams/projects, as the history will be much cleaner.