Re: Signal conflict on merging metadata-differing patches

[Junio C Hamano]

Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes:

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