Live data from Hacker News

Idiot Proof Git

softwaredoug.com

11–20 of 435 posts

Re: Idiot Proof Git

#11
post #3

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.

Couldn't you rewrite history locally on your own branch and nobody would know?

Re: Idiot Proof Git

#12
post #5

How is push origin HEAD --force-with-lease different from normal git push? Can someone please explain this to me?

It will overwrite the tree on remote as long as remote hasn't changed since you last fetched it. Like --force, but can help to prevent overwriting other people's changes when they push in between you fetching. 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

#13
post #5

How is push origin HEAD --force-with-lease different from normal git push? Can someone please explain this to me?

Force with lease is like force push except if the branch you are force pushing to has changed since you last fetched then it will cancel the force push.

Re: Idiot Proof Git

#14

Rebase (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.

A really good guide to learning this is https://git-send-email.io/.

Re: Idiot Proof Git

#15

Earlier 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?

Yeah... You should never rewrite history of shared branches. You are just asking for trouble in that case.

Re: Idiot Proof Git

#16
I'm incredibly thankful that 99% of my Git usage at work gets away with just PULL, CHECKOUT [-b], COMMIT [--amend] and PUSH. Rarely do I need to rebase, for any reason.

Re: Idiot Proof Git

#18
--force-with-lease can be a footgun.

It 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

#19

Rebase (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.

Sourcehut's tutorial on send-email is pretty good: https://git-send-email.io/

Re: Idiot Proof Git

#20
This can be fine in two scenarios: - solo dev - enforcing its use in your company

Otherwise big messes will inevitably arise. In the second case, new people with their (correct) git workflow will suffer.

Post reply on HN