Earlier quoted context omitted.
What about squashing commits in a merge? I don't do that all the time, but it is useful for certain things. Like repeated code changes to test something in the CI/CD pipeline (that I can't replicate well locally), where only the last change that got it working is of any interest.
Squashing is rewriting history. It sounds like the grandcomment had a ban against rewriting history across-the-board, which would help make git idiot proof. I love rewriting history, not because it's what I wished I had done but because it's what I am going to want to review when I have to. Rewriting history is a great way for gitiots to shoot themselves in the foot.
Idiot Proof Git
11–20 of 435 posts
Re: Idiot Proof Git
#12How is push origin HEAD --force-with-lease different from normal git push? Can someone please explain this to me?
Re: Idiot Proof Git
#13How is push origin HEAD --force-with-lease different from normal git push? Can someone please explain this to me?
Re: Idiot Proof Git
#14Rebase (non-local rebase) based workflows are just awful. The best git methodology I've seen is (surprise, surprise) in the Linux kernel. I can keep everyones tree as a separate tracking branch and use git work trees to develop against multiple branches on the same system. I also really enjoy using git request-pull, send-email, etc. and I think Github has been actively harmful in teaching people bad git habits.
any pointers on where to start for request-pull, send-email, etc. Ie, the linux kernel flow? Everything is a PR these days in github, so perhaps we find a way to do this with github.
Re: Idiot Proof Git
#15Earlier quoted context omitted.
Squashing is rewriting history. It sounds like the grandcomment had a ban against rewriting history across-the-board, which would help make git idiot proof. I love rewriting history, not because it's what I wished I had done but because it's what I am going to want to review when I have to. Rewriting history is a great way for gitiots to shoot themselves in the foot.
Couldn't you rewrite history locally on your own branch and nobody would know?
Re: Idiot Proof Git
#16Re: Idiot Proof Git
#17How is push origin HEAD --force-with-lease different from normal git push? Can someone please explain this to me?
Re: Idiot Proof Git
#18It will overwrite the tree on remote as long as remote hasn't changed since you last fetched it. It doesn't always work, particularly if you have a tool which continuously fetches remote, like an IDE configured to do so such as VSCode. In that case, you will have fetched the other person's changes, and --force-with-lease will happily blow-away anything on remote that might not be in your tree yet.
Re: Idiot Proof Git
#19Rebase (non-local rebase) based workflows are just awful. The best git methodology I've seen is (surprise, surprise) in the Linux kernel. I can keep everyones tree as a separate tracking branch and use git work trees to develop against multiple branches on the same system. I also really enjoy using git request-pull, send-email, etc. and I think Github has been actively harmful in teaching people bad git habits.
any pointers on where to start for request-pull, send-email, etc. Ie, the linux kernel flow? Everything is a PR these days in github, so perhaps we find a way to do this with github.
Re: Idiot Proof Git
#20Otherwise big messes will inevitably arise. In the second case, new people with their (correct) git workflow will suffer.