
Am 14.11.2015 um 21:10 schrieb Mike Meyer:
Since we're talking about this, ones is the reasons I dislike for is that it treats the project history just like any other prolix public document, providing tools for modifying it, changing it as you push or pull, etc. I disagree with this, and prefer tools that believe that history should be immutable, like hg and fossil.
Just curious: Why? Background: in practice, I found that git projects do not allow rewriting history that has been pulled for any coding. The changes can't be committed without rebasing, which is both somewhat advanced and potentially painful (due to merge conflicts), so it's actively avoided. There are variations such as setting aside repositories or branches for experimentation or patch preparation which may have their history rewritten, but that's just editing before the patch goes in, not a real history rewrite. So I think the difference is less relevant than most people think - but then maybe I'm overlooking something, so what's your take? Regards, Jo