From: Junio C Hamano <gitster@xxxxxxxxx> > > Christian Couder <chriscool@xxxxxxxxxxxxx> 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. Yeah, but then you might also want to have a mergetag for the updated tip of the branch and --graft will not put it in the new commit, so it would be better to use --edit in this case. > Why is it a good idea to error it out? Because sometimes, in complex cases, it is misleading to do as if you can do the right thing, when there is a good chance you cannot. > 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... I think that when "replace --graft" is used on a regular commit there is much better chance that the resulting replacement commit will be as the user expect it to be. Thanks, Christian. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html