Re: [PATCH v6 09/10] replace: check mergetags when using --graft

From: Christian Couder <chriscool@tuxfamily.org>
Date: Jul 8, 2014, 05:35 UTC
Message-ID: <20140708.073501.2265697032770915844.chriscool@tuxfamily.org>
In-Reply-To: <xmqqion8by82.fsf@gitster.dls.corp.google.com>

From: Junio C Hamano <gitster@pobox.com>

Show 21 quoted lines

>
> Christian Couder <chriscool@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.

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.

Show 5 quoted lines

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