On Sat, Mar 16, 2013 at 01:33:42PM -0700, Gavin Sharp wrote: > On Sat, Mar 16, 2013 at 12:07 PM, Andrew Sutherland > <[email protected]> wrote: > > My personal experience in mozilla-central and comm-central was that holding > > blame/annotate sacred provided a lot of stop energy to improving the state > > of code, leaving the code generally worse off. > > Indeed. Determining the original source of a particular line already > often involves looking multiple revisions back. Adding one more > because of a whitespace fix doesn't make a significant difference. > There should be no hesitation to fix whitespace due to fear of > "breaking blame". (Though of course there may be other reasons why > "fixing whitespace" isn't a good thing, and it should generally always > be done as a separate changeset).
Also: `git rebase -X ignore-space-change` can be helpful if you have to rebase across a change that alters a lot of whitespace, but beware that the resulting state may not be indented correctly and need a fixup; for me this was a definite improvement over having to hand-resolve spurious merge conflicts (and possibly get them wrong). (The thing I needed it for was a large change in Rust that added a level of syntactic nesting around a lot of code, rather than a whitespace-only change, but it should be generally applicable, I think.) --Jed _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
