3 ms·

> especially when fixing things that were mistakes in the first commit, and would have been committed as part of the first commit with more planning and/or no i

> especially when fixing things that were mistakes in the first commit, and would have been committed as part of the first commit with more planning and/or no innocuous accidents? Follow-up fixes reveal important nuance and implicit assumptions that shouldn't be erased. As for your other claims of "simply" and "easy", you need only peruse this thread that covers plenty of rebase stories losing entire commit histories and requiring redoes of weeks worth of work to see either it is neither easy or simple. Edit: See also this point by point breakdown: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

dahart 3y ago
> Follow-up fixes reveal important nuance and implicit assumptions that shouldn’t be erased That’s definitely not always true. In my experience that’s a small minority of cases, and when it happens, I keep the important nuance commits and don’t squash them. Nobody is forcing you to squash, it’s an option for the (many) fix up commits that were pure accidental oversight and have no nuance that needs to be preserved. I’ve seen lots of people claim they lost work, because they freaked out or gave up without slowing down to think carefully. The reason is because they didn’t learn how git actually works, and never learned the undo buttons. I’m well aware that git’s CLI is intimidating and unintuitive, but one thing it does not do is corrupt your repo for you. That’s effectively a blaming excuse for not having learned how it works.
dahart 3y ago
Replying to your later edit. I’m aware of Fossil’s language, which is pretty hyperbolic. It’s largely a straw-man argument, because Fossil devs have presumed to state the intentions of git devs and git users, and they jump to a bad-faith conclusion in order to state their opinion that Fossil is better than git. Keep in mind the Fossil pages are marketing, and they are comparing themselves to the competition (git) by trying to paint git in a negative light, with prejudice. They wish they had the market share that git does, and so you should trust that language just as much as you trust a Pepsi TV commercial. Dr. Hipp has stated on HN his belief that editing code history should be considered a criminal activity, without sufficient justification for such an extreme and unique point of view. BTW I have a ton of respect for SQLite and Dr. Hipp’s work. I love the way he has talked about testing. Nonetheless, I’m very much not a fan of their trash-talking of git that intentionally ignores the context, guidance, and real-world usage of rebase. The irony of them saying that git rebase is “dishonest” is that they themselves are being intentionally dishonest about how they talk about git, and I find it very off-putting and hypocritical, to be as polite as possible.

dahart 3y ago

> Follow-up fixes reveal important nuance and implicit assumptions that shouldn’t be erased That’s definitely not always true. In my experience that’s a small minority of cases, and when it happens, I keep the important nuance commits and don’t squash them. Nobody is forcing you to squash, it’s an option for the (many) fix up commits that were pure accidental oversight and have no nuance that needs to be preserved. I’ve seen lots of people claim they lost work, because they freaked out or gave up without slowing down to think carefully. The reason is because they didn’t learn how git actually works, and never learned the undo buttons. I’m well aware that git’s CLI is intimidating and unintuitive, but one thing it does not do is corrupt your repo for you. That’s effectively a blaming excuse for not having learned how it works.

dahart 3y ago

Replying to your later edit. I’m aware of Fossil’s language, which is pretty hyperbolic. It’s largely a straw-man argument, because Fossil devs have presumed to state the intentions of git devs and git users, and they jump to a bad-faith conclusion in order to state their opinion that Fossil is better than git. Keep in mind the Fossil pages are marketing, and they are comparing themselves to the competition (git) by trying to paint git in a negative light, with prejudice. They wish they had the market share that git does, and so you should trust that language just as much as you trust a Pepsi TV commercial. Dr. Hipp has stated on HN his belief that editing code history should be considered a criminal activity, without sufficient justification for such an extreme and unique point of view. BTW I have a ton of respect for SQLite and Dr. Hipp’s work. I love the way he has talked about testing. Nonetheless, I’m very much not a fan of their trash-talking of git that intentionally ignores the context, guidance, and real-world usage of rebase. The irony of them saying that git rebase is “dishonest” is that they themselves are being intentionally dishonest about how they talk about git, and I find it very off-putting and hypocritical, to be as polite as possible.