Christian Couder <chrisc...@tuxfamily.org> writes: > When using --graft, with a mergetag in the original > commit, we should check that the commit pointed to by > the mergetag is still a parent of then new commit we > create, otherwise the mergetag could be misleading. > > If the commit pointed to by the mergetag is no more > a parent of the new commit, we could remove the > mergetag, but in this case there is a good chance > that the title or other elements of the commit might > also be misleading. So let's just error out and > suggest to use --edit instead on the commit.
I do not quite understand the reasoning. If you have a merge you earlier made with a signed tag, and then want to redo the merge with an updated tip of that branch (perhaps the side branch was earlier based on maint but now was rebased on master), it will perfectly be normal to expect that the title or other elements of the resulting merge to stay the same. Why is it a good idea to error it out? If the argument were '"replace --graft" that changes the parents is likely to affect merge summary message, so error out and suggest to use --edit instead', regardless of the 'mergetag', I'd understand it, but that would essentially mean that 'replace --graft' should never be used, so... -- 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
