Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <mhng-ebcc1b82-5dd0-4f2d-824e-8d9250374abf@palmer-ri-x1c9>
In-Reply-To: <mhng-ebcc1b82-5dd0-4f2d-824e-8d9250374abf@palmer-ri-x1c9>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri, 30 Jun 2023 09:46:39 -0700
Message-ID: <CAHk-=wgqQCAtA4cVev0g3A6RCD16s1p-_TAUeVkGE0_yS2ehyA@mail.gmail.com>
Subject: Re: [GIT PULL] RISC-V Patches for the 6.5 Merge Window, Part 1
To:     Palmer Dabbelt <palmer@rivosinc.com>
Cc:     linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, 30 Jun 2023 at 08:40, Palmer Dabbelt <palmer@rivosinc.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@redhat.com>
> ++L:    platform-driver-x86@vger.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