Preserving metadata for blame/praise through whitespace changes
John Arbash Meinel
john at arbash-meinel.com
Mon Jul 6 19:21:15 BST 2009
-----BEGIN PGP SIGNED MESSAGE-----
Michael B. Trausch wrote:
> Alright, so I realize that this isn't really an issue of a VCS, since
> *all* VCSes that I am aware of do this: When you go through en masse
> and do a formatting change, such as correcting indentation, you lose the
> utility of the blame/praise functionality.
> For example, I just fixed the indentation in the AllTray source code
> repository (Vala-mode in Emacs didn't work the way I thought and I could
> not figure it out at first, so I had quite a lot of history "wrongly"
> indented). I fixed that, but now the files are all largely the last
> commit, by me. I can "bzr blame -r-2" to see the real information, but
> that isn't terribly useful until more history is present since the
> indentation change.
> So, I have two questions:
> 1. Is there something I should have done that would have preserved
> "blame" data?
> 2. If there is nothing, is there some way to educate bzr that
> whitespace-only changes should not factor in to things like diffs and
> output of commands like "bzr blame", or perhaps, be able to be removed
> from consideration by the addition of an extra parameter?
It isn't something that you can do now, but adding a "bzr annotate
- --ignore-whitespace" is something that I would like to eventually get to
with my refactoring of annotate.
I'm currently in the process of restructuring the code (at the moment
just to make it faster), but I have in mind to allow various policy
parameters such as:
1) Ignore whitespace
2) Mainline commits only (so you get an annotation of when things
*landed* not when they were committed)
3) I already have support for tracking more than one source revision (so
if someone does a cherrypick, you can potentially see that both the
original and the cherrypick introduced this text.)
Keep an eye on:
I probably won't do --ignore-whitespace as part of landing that branch,
but when I implement it, I'm sure it will be built from there.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar