On Sun, Aug 7, 2011 at 3:56 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Jeff King <peff@xxxxxxxx> writes: > > I actually am slightly against it. One-time whole-tree clean-up can never > happen without downside as _some_ parts of the tree always have patches to > conflict with it in flight. One-time decision to clearly spell out the > rules and cleaning the tree over time, fixing parts that are not actively > touched one at a time, is probably feasible, though. > I certainly agree that whole tree cleanup is disruptive when there is a lot of other stuff going on since it causes lots of merge conflicts. In my day job, I sometimes have to defer otherwise sensible refactorings because of the carnage they would cause for the daily integration. That's what I think is nice about having an easy way to automate the cleanup+test, especially if it can be applied to arbitrary refactorings. Having earlier invested the effort in creating some refactoring heuristic, you can later easily apply the heuristic completely and consistently to a file as part of some other maintenance activity. jon. -- 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