I have had the same thought. It is laborious to use and people struggle with it.
99% of the behavior it implements people do not use.
Git is not the correct level of abstraction.
99% of the behavior it implements people do not use.
Git is not the correct level of abstraction.
git init
git clone
git clone --recursive
git remote add
git checkout
git branch
git merge --no-ff
git add
git add -p
git rm
git reset
git commit [-a] [-m]
git commit -p
git commit --amend
git submodule add
git push
git push -u
git pull
git log
git show
git status
git update-index --assume-unchanged (aliased to ignore)
git update-index --no-assume-unchanged (aliased to unignore)
If we're doing something other than git I'll be happy with those. Specifically add/commit -p are important to me.
While working, I’m freely taking advantage of Git’s capabilities on a personal level, producing many sometimes messy WIP (work in progress) commits, trying things on short lived branches, reverting changes, and so forth, but afterwards I am able to copy edit the results to produce a sequence of finalized commits that form a coherent narrative that reads like how I would describe my work to a colleague or manager.
To me, interactive rebasing has been the difference between “my team uses Git” and “I first and foremost use Git for myself, and then also use it to share the results with my team”.
I like presenting and merging tidy changes.
"git blame" is also very useful.
"git bisect" is remarkably useful once a month or so. It does a binary search to find the commit that broke whatever thing you've recently discovered is broken.
Recently my coworker asked for help tracking a regression after spending hours finding the culprit, I bisected it in a couple minutes and his mind exploded :-)
And git reflog is indispensable for fixing things.
And I'm surprised you didn't mention git diff. I do that all the time to compare things, like having a single diff of all commits between the origin diff base and current HEAD. Also useful for summarizing changes of entire feature branches.
Git is like C++. People learn and use a different subset of it and everyone claims their own chosen subset is powerful enough and entirely sufficient for everyone.
Rebase -i is a lot to fun, I ought to practice it more. Haven't had to use reflog yet, but I'll be expecting it now thanks~
1 git clone
2 git cherry-pick
10 git reset
17 git merge
23 git fetch
34 git checkout
37 git rebase
66 git diff
75 git pull
79 git log
87 git branch
126 git commit
135 git add
141 git push
201 git status
205 git grep 122 git bug
124 git branch
169 git show
247 git reset
274 git rebase
308 git fetch
310 git fixup
576 git commit
633 git push
692 git pull
889 git stash
949 git diff
1122 git add
1681 git checkout
After github, things became much easier and it is likely the main reason people use git over mercurial.
Of course, now I work at a place that uses Mercurial, because Git can't handle the size of our repo (an order of magnitude, at least, bigger than the Linux kernel)...