Received-SPF: pass (google.com: domain of linux-kernel+bounces-183213-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <20240517192239.9285edd85f8ef893bb508a61@linux-foundation.org>
 <CAHk-=whEAquncw0wb59-XVAHmVh4CWSfwuWh4bTJjJzvx0=PzQ@mail.gmail.com> <20240519113639.db3fe5f80d25be4e7666751e@linux-foundation.org>
In-Reply-To: <20240519113639.db3fe5f80d25be4e7666751e@linux-foundation.org>
From: Linus Torvalds <torvalds@linuxfoundation.org>
Date: Sun, 19 May 2024 11:56:56 -0700
Message-ID: <CAHk-=wiy+25i1VZhDaV-b_m4aXGNELuVok9Prv4=oYqiun--rg@mail.gmail.com>
Subject: Re: [GIT PULL] MM updates for 6.10-rc1
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, mm-commits@vger.kernel.org, 
	linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"

On Sun, 19 May 2024 at 11:36, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> This is me advancing the master branch once per week until we hit -rc4.

Yeah. You really shouldn't do that with a merge commit.

If what you want to do is just advance the master branch, you should
just rebase on top (if rebasing is what you want to do).

Instead you seem to merge _and_ then rebase. So you do the worst of both worlds.

You don't get the history cleanup of rebasing, and you don't get the
history preservation of merging. You do both, and it's wrong.

> I don't understand why these merges were visible to this pull.  I sent:
>
> : The following changes since commit 5d1bc760583f225032f91bd88853f4c26acaf4e0:

No. That is NOT how git works.

You claiming to send only the changes after a commit doesn't magically
make the history that precedes that commit go away.

With git, when you send a branch, you send the WHOLE HISTORY. That is
fundamentally how git works. You trying to change the "from this
commit forwards" doesn't actually change anything at all, it only
changes the wording in the pull request itself.

You can't just do a pull request and try to say "only send changes
since this commit".

Git is *not* the broken sh*t that you have used before that is just a
queue of patches. Every single commit carries the whole history that
leads up to it.

And that is fundamental (and is fundamentally why patch-queue based
stuff is broken garbage), because proper history is what makes merging
work and scale. It's pretty much what makes git not CVS, or the horror
that is darcs and "patch algebra".

So when you do a pull request, the whole history is always visible.
You can't make it not visible.

> This has worked OK before,

Your previous histories haven't had those broken merges in them, so
your previous pulls haven't had them either.

I don't know what you have changed in your setup, but your "advance
the master branch once per week" process is completely broken.

The problem isn't the pull request. The source of the problem is
something in your "advance" scripting.

               Linus