<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 6, 2013 at 5:44 PM, Satish Balay <span dir="ltr"><<a href="mailto:balay@mcs.anl.gov" target="_blank">balay@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1rs">This is the clue that points to "commit" massaging/altering tools<br>
[like "rebase" - that I refer to and "gitifyhg" that Sean is pointing<br>
to] as the instigator. They don't do 'hg operation' on files - but do<br>
internal commit metadata manipulation - that can result in such<br>
"empty" diffs in commits.</div></blockquote></div><br>Barry made that commit. He does not use rebase and does not use gitifyhg.</div><div class="gmail_extra"><br></div><div class="gmail_extra" style>We may not have noticed it if I hadn't imported it through gitifyhg later, but the original commit still appears to be messed up. There is no way for gitifyhg to preserve sha1s for corrupt hg commits, we can only expoct to do it for valid commits.</div>
</div>