Hi again, Mkrtchyan, Tigran wrote: > Jonathan Nieder wrote: >> Tigran Mkrtchyan wrote: >>> In some workflows we have no control on how git command is executed, >>> however a signed tags are required. >> >> Don't leave me hanging: this leaves me super curious. Can you tell me >> more about these workflows? > > Well, this is a build/release process where we can't pass additional > command line options to git. TO be hones, is case of annotated tags > there is already option tag.forceSignAnnotated. However, non annotated > tags are not forced to be signed. > > Additionally, the proposed option is symmetric with commit.gpgSign. Now I'm even more curious. I don't think we have the full picture to understand whether this change is needed. When adding a configuration item, we need to be able to explain to users what the configuration item is for, and so far the only answer I am hearing is "because we do not want to patch our build/release script, though we could in principle". That doesn't sound like a compelling reason. On the other hand, perhaps the answer is "our build/release script does not have a --sign option for the following reason, and this is a better interface for configuring it". Or perhaps there is an answer that does not involve the build/release script. But with no answer at all, it is hard to see why we should move forward on this patch. To be clear, I am not saying that writing the patch is wasted effort. E.g. you can continue to use it internally, and it means that once we have a clear reason to add this configuration, the patch is there and ready to use to do so. Thanks again, Jonathan
