On Fri, Jul 24, 2015 at 08:04:21AM -0700, Junio C Hamano wrote: > > I think a really simple example is something like: > > > > 1. somebody implements as feature. It needs to handle cases a, b, and > > c, but it only handles case a. Therefore it is buggy. > > > > 2. During review, somebody notices case b, and a new commit is made to > > fix it. Nobody notices case c. > > > > 3. The topic is merged. > > > > 4. Much later, somebody notices the system is buggy and hunts in the > > history. > [...] > > I actually do not think the above is quite true. In our kind of > "clean history, we do not squash 1 & 2. See Paul's "rewrite am in > C" series, for example, that starts from a "buggy" (in the sense > that it does almost nothing in the beginning and then gradually > builds on). > > Instead, even somebody did not have foresight to realize 'b' when > she adds code to handle 'a', we would make sure the solution for 'a' > is sufficiently clearly described in commit #1. Sometimes. There's definitely human wisdom going into the decision to squash or make a new commit, which is a good thing. Here's a counter-example to the am series. When I wrote the object-freshening code, I accidentally inverted the test for checking whether packs were fresh. This was noticed in review, and I corrected it by inverting the is_fresh function. But in doing so, I introduced a new bug, where the test for loose objects was inverted. The original fix was squashed in the re-roll, but much later we noticed and diagnosed that new bug. It was very valuable to me to read the mailing list archive to see what happened, because the fact that there _was_ a bug fix was lost in the clean history. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html