On Wed, Jun 15, 2016 at 09:07:16AM +0200, Michael J Gruber wrote: > > Ah, so the problem is probably that you had a signature _initially_, but > > that it did not survive the rebase. Which makes sense, as rebase would > > need to re-sign. It does not by default, but you can tell it to do so > > with "-S". Or you can set `commit.gpgsign`, which should sign in both > > cases. > > While it's clear that a rebase invalidates the signature, we could try > to be more helpful here, especially given the fact that (with our model) > you can't sign a commit afterwards any more. > > commit.gpgsign signs everything, but there should be a mode for > re-signing signed commits, or at least a warning that rebase dropped a > signature so that you can --amend -S the last commit. I had a similar thought, though I'm not sure how useful a "re-sign signed commits" mode would be in practice. Mostly because I'm not sure why signing would be more important for one commit versus another. That is, I can see why somebody would set "commit.gpgSign"; their preference (or that of their project) is to sign commits, and they've set up gpg, etc, to make it relatively painless. 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). -Peff -- 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