Hacker News new | ask | show | jobs
by Karunamon 3599 days ago
Only easier to understand if the commit messages suck. If your commit messages are descriptive, and each commit is an atomic unit of work (in other words: following best practices) rebasing has thrown away history that you can never get back.
1 comments
steveklabnik 3599 days ago
Right, but often, that's not something that happens the first time around. The idea is that you rebase in order to get that kind of history 100% of the time.

You cannot get things perfect on the first try; this is part of the whole principle of code review. When my patch is perfect, except for that one little typo, what should be done? Is a history with two commits, one amazing, one saying "fix typo" with a one-character diff, or one commit that's perfect, an easier to understand history? What is actually lost by "throw[ing] away history that you can never get back"?

If it had been right in the first time, that history would have never even existed in the first place. So you end up with the exact same thing.

link
Karunamon 3599 days ago
Did that typo fix introduce a bug? Maybe, maybe not, but many programmer hours have been wasted on incorrect single characters :)

If I were bisecting that repo, it's a lot easier and more useful to be able to point the finger at the one commit that actually changed the line, rather than having to parse the one monster squashed commit to find the one line that introduced the bug.

link
steveklabnik 3599 days ago
I tend to write documentation, so no, not a bug. But even then, there's lots of small code-review things that aren't always about bugs; project style, naming conventions, etc.

Furthermore, if this is a PR that's open, then the "bug" would have never even landed. So looking through history to "find what caused the bug" would have not even been a thing.

link