Imperfect round-trip of Miri repo due to gpgsig

[RalfJung]

When applying josh to https://github.com/rust-lang/miri, doing a round-trip that should be the identity nevertheless produces a result with a different hash:

git clone https://github.com/rust-lang/miri
cd miri
# do this in 2 steps because otherwise josh is too clever and doesn't do any work
josh-filter :prefix=extra refs/heads/master --update refs/heads/filtered
josh-filter :/extra refs/heads/filtered --update refs/heads/double-filtered
git diff refs/heads/master refs/heads/double-filtered
# no output, as expected
git rev-parse refs/heads/master refs/heads/double-filtered
# two different SHAs

I went through our history to see where the difference starts, and it is this commit. show --pretty=raw also shows why:

commit 6abfa56b20009546be67837cc7cd92c9c13f5951
tree b450b00d80b565f5ef7f93660af60468b6add237
parent 8cac01ae66a8eebca4711a5771ad161cb8f498ba
author Pascal Hertleif <killercup@gmail.com> 1460584860 +0200
committer Pascal Hertleif <killercup@gmail.com> 1460584860 +0200
gpgsig -----BEGIN PGP SIGNATURE-----
 Comment: GPGTools - http://gpgtools.org
 
 iEYEABECAAYFAlcOwccACgkQ7bsajSBHoHQp+gCgqi423y1LEedj4qkVGvdzGx28
 OXQAnijThOzObWreOk0wRMZ8RvTE7/EK
 =q0is
 -----END PGP SIGNATURE-----

    Update to Rust Nightly 2016-04-11

diff --git a/src/interpreter.rs b/src/interpreter.rs
index 850ddf8aa18..a1db521760f 100644
--- a/src/interpreter.rs
+++ b/src/interpreter.rs
@@ -1,7 +1,7 @@
 use arena::TypedArena;
 use rustc::infer;
 use rustc::middle::const_val;
-use rustc::middle::def_id::DefId;
+use rustc::hir::def_id::DefId;
 use rustc::mir::mir_map::MirMap;
 use rustc::mir::repr as mir;
 use rustc::traits::{self, ProjectionMode};

The gpgsig part is lost after josh did its thing.

Obviously the signature is broken on the intermediate trees, but given that the josh design goal is a perfect roundtrip, this still seems like a bug.

[christian-schilling]

Yes, that is true. Signatures are lost when filtering because they cannot be valid for filtered commits. Once lost we can't recover them.
I looked at your change now and I'm shocked that it seems to work :)
So git does not mind for a invalid signature being present in the commit?

[RalfJung]

I don't know if and when git validates signatures. That would probably be good to figure out. :) But the testcase works, is all I can say.

Given that we have singed commits in the Miri history, I think we pretty much need this to round-trip properly. Otherwise if, in the future, someone pushes a signed commit to Miri, the syncing round-trip will do some awkward duplication of that change and probably end up conflicting with itself...

[RalfJung]

Looking at https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work and other resources I found only, it doesn't seem like git will verify anything by default, and validation will validate only the commit in question, not the signatures in the history (which makes sense since the signature signs the history due to the hashing).

Maybe this should be a user-configurable option, controlling globally whether signatures should be preserved or not.

[christian-schilling]

I think knowing that now, we can just preserve the signatures (apply #958)
This will solve the "imperfect roundtrip" issue and I think if somebody needs smarter handling of "partial signatures" that could maybe build on top of that.