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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 18 Nov 2019 18:35:17 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Eugeniu Rosca <erosca@...adit-jv.com>
Cc:     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

On Mon, Nov 18, 2019 at 06:29:17PM +0100, Eugeniu Rosca wrote:
> Dear Git community,
> 
> Due to high inflow of patches which Linux maintainers carry on their
> shoulders and due to occasionally intricate relationships between
> consecutive revisions of the same series, it may [1] happen that two
> distinct revisions of the same patch (differing only/mostly in
> metadata, e.g. Author's time-stamp and commit description) may end up
> being merged on the same branch, without git to complain about that.

Why would git complain about that?

> Is there any "git merge" flag available off-the-shelf which (if used)
> would signal such situations?

I don't understand what you are looking for here.  Two different
versions of the patch were merged to different branches and then merged
together, and git did the right thing with the resolution of the code.

What more can it do here?

thanks,

greg k-h