
On 15 November 2015 at 09:37, Mike Meyer
On Sat, Nov 14, 2015 at 2:52 PM Joachim Durchholz
wrote: 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?
Philosophical. I want history to reflect the way things actually happened.
So I think the difference is less relevant than most people think - but then maybe I'm overlooking something, so what's your take?
I'm not convinced that a rebase in lieu of a merge doesn't hide where bugs are introduced. But that's minor to not wanting history hidden. I even had someone ask that I collapse a bunch of changes when I pushed them to my github repo before creating a PR. Not going to happen.
On the other hand, when accepting a PR, I don't want it to be full of lots of little "let's see if this worked; nope I need a second commit" messages cluttering up the git log: I recently had such a case where there were empty commits called "test commit", etc. Or in my own work, if I accidentally forgot to include a hunk in a commit I prefer to squash that change with the commit it was meant to be in rather than have an extra commit. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com