linux-kernel - Re: [GIT PULL] MM updates for 6.10-rc1

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: Sun, 19 May 2024 11:56:56 -0700
From: Linus Torvalds <torvalds@...uxfoundation.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-mm@...ck.org, mm-commits@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] MM updates for 6.10-rc1

On Sun, 19 May 2024 at 11:36, Andrew Morton <akpm@...ux-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