Re: Signal conflict on merging metadata-differing patches

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 19, 2019, 02:04 UTC
Message-ID: <xmqqo8x8zknn.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20191118194804.GA662468@kroah.com>

Greg KH <gregkh@linuxfoundation.org> writes:

Show 8 quoted lines

>> I don't advocate for "git merge" to fail in the above scenarios. No.
>> I just say that Git could likely detect such scenarios and help people
>> like you not pushing v2 and v5 of the same patch into the main tree.
>
> But what should it do in either of those above situations?  Fail the
> merge?  No, that's not ok as those different branches were just fine on
> their own and I will never expect them to be rebased/rewritten just for
> something like this.  That's crazy.

;-)

I agree that the requested "feature" would make no sense for kernel maintainers at various levels, as long as they are dealing with merges among published branches. What's done at the submaintainers' trees are better treated as "already cast in stone".

It may be a useful feature when one maintains a bag of local/private branches that haven't been published, though. I however do not know what its implementation would look like X-<.