Hi, On Fri, 11 Jul 2008, Lea Wiemann wrote: > Patch (3) basically makes two large changes in one patch, but it was > pretty hard to separate them during development. I could try to split > them up after the fact, but it would take at least an hour or two, since > the changes that introduce caching are spread all over the code. I > don't think that having separate commits ([a] use Git::Repo API, [b] add > caching) brings enough benefit to justify the effort. > > There are some other changes in (3) as well, but they fell out as part > of the refactoring, so I didn't separate them either -- same thing. FWIW there are a few reasons why splitting up (3) might be the thing you really want to do, even if it takes an hour or two: - it makes reviewing much easier, - it makes subsequent revisions of the patches easier to review, - it make it easier to cherry-pick changes, should not all be equally liked, - it makes finding bugs much easier (both spotting during review and bisecting), and - it is good for documentation purposes, should someone read the commit log. Now, after weighing the benefit (especially in terms of hours spared others) against the downsides, you might want to reconsider your stance. Ciao, Dscho -- 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
