4 ms·

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 l

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.

kohtatsu 7y ago
Here is an exhaustive (~99.5%) list of the git commands I use: 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) The 1 in 200 is probably a git rebase -i. If we're doing something other than git I'll be happy with those. Specifically add/commit -p are important to me.
- linuxftw 7y ago
  I always recommend to people to not use 'git pull' as it's probably not what you really want.
  - 3JPLW 7y ago
    What do I want? It sure seems to do exactly what I need in the case where I'm on my local `master` and it's exactly the state of `origin/master` but a day or two behind.
    - linuxftw 7y ago
      What is it you're doing on your local master? It's only going to lead to a mess if you're developing on master locally and trying to do merges from upstream.
      - 3JPLW 7y ago
        Absolutely no development. I use it as my starting point for feature branches, as well as subsequent rebases and merges on them. And I use it to build and run the current master.
- alasdair_ 7y ago
  "git stash" is something I used to use all the time, roughly daily. "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.
  - 1_player 7y ago
    Bisect might be one of git’s killer features: you rarely reach for it, but when you do it saves your ass and saves the day. 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 :-)
- pdmccormick 7y ago
  I’d encourage anyone using Git take a closer look into “git rebase -i” (interactive rebasing) combined with “git add -i” (interactive staging). 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”.
  - Rapzid 7y ago
    I nearly always "git rebase -i" before opening a PR, and even after. Squash, re-order, reword FTW. Recently I started using "edit" to split previously squashed PRs back out. I like presenting and merging tidy changes.
- words3425434 7y ago
  me]$ cat .bash_history | grep git | awk '{print $1,$2}' | sort | uniq -c | sort -n 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
  - daurnimator 7y ago
    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 Where `fixup` is https://github.com/hashbang/dotfiles/blob/master/git/.local/bin/git-fixup https://github.com/hashbang/dotfiles/blob/master/git/.local/...
- kccqzy 7y ago
  I run git rebase -i a lot more often because I like to reword a bunch of commits to make the commit messages clearer just before pushing. 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.
  - kohtatsu 7y ago
    Darn I actually missed git diff. I haven't been using a bash history so I don't have something check against. I'm confident now it's complete tho. 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~
dhimes 7y ago
I don't use git; years ago I chose mercurial and have stuck with it. And I'm by no means a power user. But I've always wondered why git "won".
- alasdair_ 7y ago
  git before github existed was a pain to use. I honestly just continued to use SVN because the tool support (like automatic renaming in IntelliJ when refactoring a class) just worked, and there was concern about exactly how to back up our source code. 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)...
  - foobarian 7y ago
    git even before github was a game changer for distributed development, kernel being the most prominent example. It did not require random people to have connectivity or authorization on some central SVN server, and yet they could clone and sync their trees and create branches to their heart's content.
    - dhimes 7y ago
      But mercurial was also in play then and seemed better (which is why I chose it) or at least on par. Somehow git got more traction and is now the default.

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.

kohtatsu 7y ago

Here is an exhaustive (~99.5%) list of the git commands I use: 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) The 1 in 200 is probably a git rebase -i. If we're doing something other than git I'll be happy with those. Specifically add/commit -p are important to me.

linuxftw 7y ago
I always recommend to people to not use 'git pull' as it's probably not what you really want.
- 3JPLW 7y ago
  What do I want? It sure seems to do exactly what I need in the case where I'm on my local `master` and it's exactly the state of `origin/master` but a day or two behind.
  - linuxftw 7y ago
    What is it you're doing on your local master? It's only going to lead to a mess if you're developing on master locally and trying to do merges from upstream.
    - 3JPLW 7y ago
      Absolutely no development. I use it as my starting point for feature branches, as well as subsequent rebases and merges on them. And I use it to build and run the current master.
alasdair_ 7y ago
"git stash" is something I used to use all the time, roughly daily. "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.
- 1_player 7y ago
  Bisect might be one of git’s killer features: you rarely reach for it, but when you do it saves your ass and saves the day. 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 :-)
pdmccormick 7y ago
I’d encourage anyone using Git take a closer look into “git rebase -i” (interactive rebasing) combined with “git add -i” (interactive staging). 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”.
- Rapzid 7y ago
  I nearly always "git rebase -i" before opening a PR, and even after. Squash, re-order, reword FTW. Recently I started using "edit" to split previously squashed PRs back out. I like presenting and merging tidy changes.
words3425434 7y ago
me]$ cat .bash_history | grep git | awk '{print $1,$2}' | sort | uniq -c | sort -n 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
- daurnimator 7y ago
  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 Where `fixup` is https://github.com/hashbang/dotfiles/blob/master/git/.local/bin/git-fixup https://github.com/hashbang/dotfiles/blob/master/git/.local/...
kccqzy 7y ago
I run git rebase -i a lot more often because I like to reword a bunch of commits to make the commit messages clearer just before pushing. 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.
- kohtatsu 7y ago
  Darn I actually missed git diff. I haven't been using a bash history so I don't have something check against. I'm confident now it's complete tho. 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~

dhimes 7y ago

I don't use git; years ago I chose mercurial and have stuck with it. And I'm by no means a power user. But I've always wondered why git "won".

alasdair_ 7y ago
git before github existed was a pain to use. I honestly just continued to use SVN because the tool support (like automatic renaming in IntelliJ when refactoring a class) just worked, and there was concern about exactly how to back up our source code. 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)...
- foobarian 7y ago
  git even before github was a game changer for distributed development, kernel being the most prominent example. It did not require random people to have connectivity or authorization on some central SVN server, and yet they could clone and sync their trees and create branches to their heart's content.
  - dhimes 7y ago
    But mercurial was also in play then and seemed better (which is why I chose it) or at least on par. Somehow git got more traction and is now the default.