linux-kernel - Re: [GIT PULL] RISC-V Patches for the 6.5 Merge Window, Part 1

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:   Fri, 30 Jun 2023 09:46:39 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Palmer Dabbelt <palmer@...osinc.com>
Cc:     linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] RISC-V Patches for the 6.5 Merge Window, Part 1

On Fri, 30 Jun 2023 at 08:40, Palmer Dabbelt <palmer@...osinc.com> wrote:
>
> There's one merge conflict in MAINTAINERS

Yes, but your suggested resolution is wrong. That "ACPI SERIAL ..."
entry was moved downwards to be in the right place alphabetically, so
the entry next to your new RISC-V entry actually needs to be removed.

You seem to just have kept it, so your resolution caused a dup.

The hint from git is the '++' at the beginning of the line:

> ++ACPI SERIAL MULTI INSTANTIATE DRIVER
> ++M:    Hans de Goede <hdegoede@...hat.com>
> ++L:    platform-driver-x86@...r.kernel.org
> ++S:    Maintained
> ++F:    drivers/platform/x86/serial-multi-instantiate.c
> ++

which means that git thinks that your merge added those lines from
thin air (ie they didn't exist in either parent).

NOTE! A '++' line is not a sign of a mis-merge in general. It is
*purely* a hint. It happens for perfectly fine merges when you either
end up moving lines around enough that git doesn't see where they came
from.

Or, perhaps more commonly, when the merge conflict was due to both
sides changing the same exact same code, and the merge resolution
comes from neither one directly, but is new code that has combinations
of both changes.

Anyway, don't worry about it, I appreciate the heads-up regardless and
I always do my own merge resolutions. I just decided to try to use
this as a "this is how git works" moment.

Basically, trivial merges where things were just added or removed next
to each other will normally not result in "++" or "--" lines, so it
can be a hint that something went wrong if you *thought* your merge
was trivial, but git gives that kind of output for the end result.

But don't think that "++" means "wrong". It really is just a sign that
maybe the merge resolution needed a lot of care. And sometimes it's
entirely a false positive - if git *really* understood merges 100%
correctly all the time, we'd never need any manual conflict resolution
at all ;)

                  Linus