If a merged commit wants to delete a locally added file, and this locally added file matches the content which was deleted in the commit being merged, we can go ahead with the deletion because there is no risk of data loss. fixes the histedit problem reported by jrick on freenode

If a previous commit introduces a new file, and it is folded into a commit that deletes the same file, the file still exists after the histedit. reported by jrick on freenode

ok stsp

Previous default output remains when test cases are run individually. ok tracey

While merging a commit multiple times during a histedit operation could potentially make sense in some corner case, a commit appearing more than once in the script is more likely to happen accidentally. If desired, the same effect can still be achieved by running multiple histedit operations, or by using 'got cherrypick' while the histedit operation is paused for arbitrary editing.

Commit IDs on histedit's temporary branch can change arbitrarily because the user may create new commits on this branch while editing past commits. So there is no point in trying to verify these IDs like we do during rebase. Add a test case which demonstrates the problem.