From: Christian Couder Date: Mon, 30 Jun 2014 10:52:29 GMT Subject: Re: [PATCH v3 1/4] replace: add --graft option Message-ID: In-Reply-To: On Mon, Jun 30, 2014 at 8:37 AM, Junio C Hamano wrote: > Christian Couder 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 ''" 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.