linux-kernel - Re: Signal conflict on merging metadata-differing patches

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 19 Nov 2019 11:04:28 +0900
From:   Junio C Hamano <gitster@...ox.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Eugeniu Rosca <erosca@...adit-jv.com>, git@...r.kernel.org,
        linux-kernel@...r.kernel.org, Felipe Balbi <balbi@...nel.org>,
        Eugeniu Rosca <roscaeugeniu@...il.com>
Subject: Re: Signal conflict on merging metadata-differing patches

Greg KH <gregkh@...uxfoundation.org> 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-<.