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]
Message-ID: <CAHk-=wirdKHYK_T=Pdx7eLP7z04P_q4zrT3uOod=dCWtmYPe8g@mail.gmail.com>
Date:   Wed, 14 Oct 2020 12:15:55 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Joerg Roedel <joro@...tes.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        iommu <iommu@...ts.linux-foundation.org>
Subject: Re: [git pull] IOMMU Updates for Linux v5.10

On Tue, Oct 13, 2020 at 9:04 AM Joerg Roedel <joro@...tes.org> wrote:
>
> there is a minor conflict this time in include/linux/iommu.h which
> should be easy to resolve. I would attach my resolution, but somehow git
> [show|log] didn't show it to me.

So when a resolution takes one side over the other (as opposed to
mixing two sides), then "git show" doesn't show it as a conflict any
more.

The reason is simple: at "git merge" time, git figures out the common
base, so it has all of "base", "side1" and "side2" to look at and does
a three-way diff (for the simplified normal case). So it can see it as
a conflict, because it sees both where you came from, and where you
ended up.

But once you have resolved the conflict and committed the end result,
"git show" (and "git log") doesn't do the whole expensive "what was
the base" thing any more. "git show" just sees the parents (so "side1"
and "side2") and the end result, but doesn't really see - or care -
about the fact that some time in the distant past you also had that
"base" state.

As a result, "git show" doesn't ever really understand the notion of a
"merge conflict", and all it shows is really "whee, this end result
looks like neither side" as a kind of pseudo-conflict diff.

Anyway, thanks for the describing the conflict, it was indeed not
complicated, this email is just to explain your "but somehow git
[show|log] didn't show it to me" thing.

                   Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ