Hi Jonathan, I can't disagree with you - the right solution is to fix the build/release process to support signed tagging. It's just too many of them to fix: jenkins, maven, IDE, etc. My naive assumption was that if a tool (git) has a switch to enable some functionality, why not have a possibility to make it default. You can put this change on hold and re-consider it if more people will need such functionality. Thanks, Tigran. ----- Original Message ----- > From: "Jonathan Nieder" <jrnieder@xxxxxxxxx> > To: "Tigran Mkrtchyan" <tigran.mkrtchyan@xxxxxxx> > Cc: "git" <git@xxxxxxxxxxxxxxx> > Sent: Thursday, October 26, 2017 11:33:37 PM > Subject: Re: [PATCH] tag: add tag.gpgSign config option to force all tags be GPG-signed > 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
