On Mon, Jun 30, 2014 at 8:37 AM, Junio C Hamano <gits...@pobox.com> wrote: > Christian Couder <christian.cou...@gmail.com> writes: > >> Now, after having read the recent thread about "git verify-commit", I >> understand >> that you also want me to drop the signature of a tag that was merged, because >> such signatures are added to the commit message. > > Huh? I am not sure if I follow. Perhaps we are talking about > different things?
I think we are talking about the same thing but I might not have been clear. > When you are preparing a replacement for an existing commit that > merges a signed tag, there are two cases: > > - The replacement commit still merges the same signed tag; or > > - The replacement commit does not merge that signed tag (it may > become a single-parent commit, or it may stay to be a merge but > merges a different commit on the side branch). > > In the former, it would be sensible to keep the "mergetag" and > propagate it to the replacement; it is a signature over the tip of > the side branch being merged by the original (and the replacement) > merge, and the replacement will not affect the validity of the > signature at all. Ok, this is what is done right now by the patch series. > In the latter, we do want to drop the "mergetag" > for the parent you are losing in the replacement, because by > definition it will be irrelevant. Yeah, it might be a good idea to drop the "mergetag", but note that anyway such a commit probably has a title like "Merge tag '<tag>'" and we won't automatically change this title and this title will be wrong (because we are not merging anymore this tag). So anyway in this case, --graft will do something that is not good. So it might be better in this case to just error out and say that it would be better to use --edit instead of --graft. -- 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
