Jeff King <peff@xxxxxxxx> writes: > But why does somebody run "commit -S" for a single commit, but not all > the time? Is it because that commit is special? Or is that particular > moment special? One implies that it's important for the signature to be > retained during a rebase, and one does not. > > So I dunno. I would not be opposed to such a feature, but I'm having > trouble figuring out why it would be useful (though for the most part, I > do not see why anything but per-project commit.gpgSign config is > particularly useful. Maybe I just lack imagination). I am not so imaginative, either. One remotely plausible use case may be a project that has two classes of paths (let's call these classes sensitive and others), and requires its participants to sign commits that touch sensitive paths. The user needs something finter grained than per-project commit.gpgSign there. But even in such a case, the fact that an original commit is with a signature should not be a good indication that the rewritten version of that commit in the new history still touches the sensitive paths that required the original to be signed (i.e. the history the user is rebasing onto may already have the necessary changes to these paths). So, I dunno, either. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html