Mark McLoughlin <[EMAIL PROTECTED]> wrote: > On Thu, 2008-04-10 at 09:29 +0200, Jim Meyering wrote: > >> Mark McLoughlin <[EMAIL PROTECTED]> wrote: >> > On Wed, 2008-04-09 at 20:42 +0200, Jim Meyering wrote: >> >> Any global space-changing delta like these is going to cause >> >> trouble (conflicts) for people with pending changes and on branches. >> > >> > IMHO, the bigger issue with patches like this is that it makes digging >> > into the history with "cvs annotate" a pain. >> >> In that case, just use git. > > Fully on-board with that, but it would still be an annoying artifact > when poking through history with git too. Less so, sure. > >> True, a global change like this does obscure the most basic annotate >> output. Though, as I said, what I'm doing isn't that big -- and nowhere >> near as bad as filtering all of the code through indent. > > Yep, my point was not so much an objection to this particular change, > but that if one consistently dismisses the concern about reducing the > usefulness of a codebase's history and continue cleanups like this > ad-nauseum, then one ends up with near-useless history.
No risk of that, imho. Such clean-ups tend to make the code converge on a well-defined style pretty quickly -- either that or they just stop. > (But you must know this - core-utils has plenty of history :-) Not too many grey hairs, yet ;-) I've inflicted far worse on a few large, non-public code bases, and in retrospect, these changes have been universally appreciated, mostly because everyone sees and uses the code on the trunk all the time, yet only a few "special" souls end up doing VCS archeology. And even those lucky few learn quickly that it's not hard to skip past any global-changes. Of course, if you have a few active branches, the value of making global changes goes down very quickly. Appearance counts for a _lot_. If the code looks sloppy, or renders strangely, that can discourage people who might otherwise take good care of it, making the sorts of tiny (sometimes nearly pointless) changes that eventually lead to that ideal, perfect-looking project. Most people are surprised to see how many "real" bugs end up being exposed (or avoided, but we can't count *those*) by changes like this. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
