Should commit-diff sign the diff to the first parent?

[Ekleog]

commit abcdef diff is currently defined as signing the diff with “the” parent.

However, a commit can have multiple parents. So when signing a merge commit, do you think this should mean:

1. Signing the whole diff introduced by the merge commit into the first-parent, thus reducing the number of signatures that need to be checked
2. Signing the diff between the result of an automatic merge (including merge conflicts), thus making a merge commit easier to sign

I'm personally in favor of option 1. And you?

[oxij]

I think it should be option 3: "I hereby sign that the resulting state is a good merge of both parents assuming both parents are good." It is, semantically close to option 2, but not quite.

I don't want option 1 because it won't work for long-running branches. Think SLNOS gets merged into NixOS, would you want to check the skyscraper-sized diff? I would not.

I don't want option 2 because it would then depend on automatic merge algorithm used.

Option 3 is like option 2, but without the merge algorithm. You can think of it as signing diffs to both parents under assumption that diffs from their parents to their grandparents are already verified to be correct.

My model is that git-wotr should be an inductive proof checker on a semilattice of signed commits. State signatures are induction bases, diff signatures are induction steps.

[Ekleog]

Didn't think about long-running branches, indeed. Actually, in a more likely-to-happen-someday view, staging is an example of something that wouldn't work with option 1.

Your view on what git-wotr should be sounds good, and I hadn't thought of it this way… thanks! Now, to turn that into words that can be easily understood for the RFC…