On Mon, Mar 21, 2016 at 12:43:45PM -0700, Junio C Hamano wrote: > > You know that when you have sign configuration enabled globally annotate is > > implicite, so its difficult to join both world. > > Sorry, I am not sure what you mean by that. It is unclear what two > worlds you are referring to.
Command line options and configuration, but forget about it. > > > I use same idea as in your patch > > `55ca3f99ae4895605a348322dd2fc50f2065f508`. > > That is not a good comparison. 55ca3f99 (commit-tree: add and > document --no-gpg-sign, 2013-12-13) is about signed commit, and over > there there are only two choices, i.e. a commit that corresponds to > an annotated tag, and a signed commit that corresponds to a signed > tag. There is no "lightweight-tag" equivalent. > > >> If you are forcing users to always leave a message and then further > >> forcing users to always sign with the single new configuration, i.e. > >> > >> $ git tag v1.0 > >> ... opens the editor to ask for a message ... > >> ... then makes the user sign with GPG ... > > > > I'm not forcing this type of user to enable global configuration, that will > > be > > annoying for them of course. > > Good. > > If so, then the configuration is "when the user gives us a message > to create a tag without explicitly saying -a/-s, we create an > annotated tag by default, but create a signed tag instead in such a > case", I would think. That is: > > $ git tag -m 'foo' $tagname > > would create signed tag under such a configuration option, and I > think such an option may make sense. And the way to override it > would be > > $ git tag -a -m 'foo' $tagname > > So there is no need for --no-sign option. When the user explicitly > asks to create an annotated tag with > > $ git tag -a -m 'foo' $tagname > > it is unreasonable to override that explicit wish with a > configuration setting. > Ah, I think I understand now, I think this will not take to much effort to fix. -- Laurent -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
