Hacker News Reader

Comment by stygiansonic | Hacker News Reader

If this is a guide for beginners, there should be (more?) warnings not to do history rewriting operations on commits that have already pushed.

View on HN

If you read to the bottom:

> Disclaimer: I am not, nor do I even remotely claim to be, an expert at git. This site is not intended to be an exhaustive reference, nor is it a beginner's tutorial. And yes, there are other ways to do these same things with more theoretical purity or whatever, but I've come to these steps through trial and error and lots of swearing and table flipping, and I had this crazy idea to share them with a healthy dose of levity and profanity. Take it or leave it as you will!

From the disclaimer at the bottom:

> This site is not intended to be an exhaustive reference, nor is it a beginner's tutorial.

It may not be intended to be a beginner's tutorial, but it is. Someone who needs to be told about `git commit --amend` and `git diff --staged` also needs to be warned about rewriting history that has been shared with others.

Why is recovering from an upstream rebase considered more problematic than recovering from merge conflicts?

Who said anything about recovering. First we'll have to determine if upstream is supposed to be used in a rebase workflow or a merge workflow.

Seems they agree:

> This site is not intended to be an exhaustive reference, nor is it a beginner's tutorial.

Reply on news.ycombinator.com