8 ms·
I think a large part of git's history rewriting stems from the desire to be able to mail features around as atomic commits. You don't want to be cluttering up y
by LogicHoleFlaw 18y ago
I think a large part of git's history rewriting stems from the desire to be able to mail features around as atomic commits. You don't want to be cluttering up your patch set with spurious interim changes.
- lanaer 18y agoAs a git user, I appreciate being able to squash commits together to keep things tidy for those who pull down my changes later — rather than seeing scattered changes that is merged with their own work, possibly interleaved with their own local un-pushed commits, they get one atomic commit for a feature. That being said, I’m pretty sure Hg gives the same ability through the use of patch queues, which probably makes more sense.
- gecko 18y agoMercurial's patch queues ultimately provide very similar benefits and drawbacks to git rebasing, except that: 1. Patch queues may be version indefinitely, since they are their own Mercurial repository, rather than eventually expiring, like rebased commits in the git reflog; but 2. The above requires you maintain discipline in committing the state of your patch repository Although the second can be trivially automated, the default behavior--rewriting your patch whenever you issue `hg qrefresh`--is far from optimal.