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
>> 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