5 ms·

> And if I push without first pulling, must it always punish me with a merge commit? Can't I say "oh shit I don't want to do this, go back and git pull"? This

> And if I push without first pulling, must it always punish me with a merge commit? Can't I say "oh shit I don't want to do this, go back and git pull"? This is a source of probably 50% of my "ah, fuck, time to undo..." moments with git, these days. I hate that shit. Muscle-memory gets ahead of me and I commit on a shared remote branch, which would be fine given our workflow except that I didn't pull first. What a pain in the ass.

lamontcg 5y ago
I guess I have `git pull --rebase` as muscle memory. I would guess there's an easy way to make git do this automatically for you via config so you never forget, but I just never, ever `git pull` Or: > git config --global alias.up '!git fetch && git rebase --autostash FETCH_HEAD' From: https://github.com/JKrag/git-up https://github.com/JKrag/git-up
- deleted 5y ago
  [deleted]
- rjmunro 5y ago
  git config --global pull.rebase true You probably also want: git config --global rebase.autostash true
- deleted 5y ago
  [deleted]
funkymike 5y ago
I have this in my .gitconfig so the pull will fail rather than merge. [pull] ff = only If it does fail I can decide whether to merge or rebase.
Nullabillity 5y ago
For the sake of your coworkers (and your future self), please don't lie just to make your history look pretty.
- DangitBobby 5y ago
  I try to make each commit a snapshot of a working repository (compileable or runnable or testable, whatever is the heuristic for working) where the difference between each snapshot can be explained by the commit message. Ideally they are isolated to a single logical "unit" of change (fix, refactor, add, remove). The goal here being to minimize the amount of confusion and work for anyone traveling up and down the tree. I often have to rewrite my local history to make this happen, because the actual changes that I make can happen in a somewhat arbitrary order. How has local history revision bitten you?
  - lmm 5y ago
    Rebasing leads to either having long stretches of non-compiling commits in history or giant non-bisectable commits. E.g. you added a method call on your feature branch, that method was renamed in master while you were working on your feature. If you merge then your commits still compile and I can use automated `git bisect` the way it's intended. If you rebase then your commits don't compile and I can't bisect through commits on your feature branch. If you squash then your whole feature development becomes a single monster commit and I can't bisect through it. I agree with having as many commits as possible be compilable, but that's not the sole criterion, because there's a tension between that and having granular history: if you squash the whole history of the repo into a single commit then that means 100% of commits are compilable, but it's still a bad move. Conversely, a non-compiling commit in between two compiling commits is not a big problem (you just make sure your git bisect script skips non-compiling commits) - what really matters is keeping the diff between two successive compiling commits as small as possible. IME the best way to achieve that is never rewriting history.
    - DangitBobby 5y ago
      That's a very good point with rebasing. Thanks for explaining.

lamontcg 5y ago

I guess I have `git pull --rebase` as muscle memory. I would guess there's an easy way to make git do this automatically for you via config so you never forget, but I just never, ever `git pull` Or: > git config --global alias.up '!git fetch && git rebase --autostash FETCH_HEAD' From: https://github.com/JKrag/git-up https://github.com/JKrag/git-up

deleted 5y ago
[deleted]
rjmunro 5y ago
git config --global pull.rebase true You probably also want: git config --global rebase.autostash true
deleted 5y ago
[deleted]

funkymike 5y ago

I have this in my .gitconfig so the pull will fail rather than merge. [pull] ff = only If it does fail I can decide whether to merge or rebase.

Nullabillity 5y ago

For the sake of your coworkers (and your future self), please don't lie just to make your history look pretty.

DangitBobby 5y ago
I try to make each commit a snapshot of a working repository (compileable or runnable or testable, whatever is the heuristic for working) where the difference between each snapshot can be explained by the commit message. Ideally they are isolated to a single logical "unit" of change (fix, refactor, add, remove). The goal here being to minimize the amount of confusion and work for anyone traveling up and down the tree. I often have to rewrite my local history to make this happen, because the actual changes that I make can happen in a somewhat arbitrary order. How has local history revision bitten you?
- lmm 5y ago
  Rebasing leads to either having long stretches of non-compiling commits in history or giant non-bisectable commits. E.g. you added a method call on your feature branch, that method was renamed in master while you were working on your feature. If you merge then your commits still compile and I can use automated `git bisect` the way it's intended. If you rebase then your commits don't compile and I can't bisect through commits on your feature branch. If you squash then your whole feature development becomes a single monster commit and I can't bisect through it. I agree with having as many commits as possible be compilable, but that's not the sole criterion, because there's a tension between that and having granular history: if you squash the whole history of the repo into a single commit then that means 100% of commits are compilable, but it's still a bad move. Conversely, a non-compiling commit in between two compiling commits is not a big problem (you just make sure your git bisect script skips non-compiling commits) - what really matters is keeping the diff between two successive compiling commits as small as possible. IME the best way to achieve that is never rewriting history.
  - DangitBobby 5y ago
    That's a very good point with rebasing. Thanks for explaining.