3 ms·
Sure, but my guess is it's just as easy to shoot yourself in the foot with rebase -i. Beginners are still going to have a hard time recovering mistakes with reb
by collinmanderson 10y ago
Sure, but my guess is it's just as easy to shoot yourself in the foot with rebase -i. Beginners are still going to have a hard time recovering mistakes with rebase -i, even if it's theoretically possible to recover.
Plus, now you need to use `git diff origin` rather than `git diff` to see your changes.
- dahart 10y ago> Sure, but my guess is it's just as easy to shoot yourself in the foot with rebase -i. No. rebase -i goes in the reflog. stashes don't. The rebase man page does not have the same safety warning that the stash man page does. I have personally witnessed a lot of stash accidents, and not many rebase accidents. With a rebase, if you have a bad merge conflict, you can abort. With a stash you can't. If you've committed your changes and have problems either forgetting what you're doing, or with merge conflicts, or with being in the wrong branch. All of these cases have more undo options with commits. In the worst case, you still have the safety net of the reflog with commit. With stashes, your only safety net is hunting for dangling blobs using fsck. Previous threads: https://news.ycombinator.com/item?id=12613062 https://news.ycombinator.com/item?id=12613062 https://news.ycombinator.com/item?id=12622414 https://news.ycombinator.com/item?id=12622414
- collinmanderson 10y agoI mean it's just as easy to make a mistake in the first place with rebase -i. Even though one is theoretically possible to recover with rebase -i, it's going to be very hard to recover for a beginner. (You need to know the reflog command, etc.)