[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAHk-=whEet1xGS14_x9hcbgXuYRFwqkTuw2AbM-UYZ=mc3Zmhw@mail.gmail.com>
Date: Wed, 7 Aug 2019 12:27:02 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Micah Morton <mortonm@...omium.org>
Cc: Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
linux-security-module <linux-security-module@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] SafeSetID MAINTAINERS file update for v5.3
On Tue, Aug 6, 2019 at 9:32 AM Micah Morton <mortonm@...omium.org> wrote:
>
> Unfortunately I didn't have the mental model quite right of what
> happens during the pull request. I was thinking along the lines of my
> commits being cherry picked onto your tree, rather than how it
> actually happens with git merge where my tree's commit history needs
> to match yours perfectly.
The "cherry-pick" model is what "git pull --rebase" does in reverse
(ie it pulls the exact history from the other end, and then rebases
the _local_ history on top of that).
But the cherry-picking model is entirely inappropriate for any bigger
project. Yes, you can do it locally on your _local_ small changes (but
see all the docs about why rebasing is not a great thing), but it's
entirely unmanageable and doesn't scale in the big picture.
It's why all the projects that were based on patch series were
complete and utter failures. A "patch series" only works locally. It's
not reasonable to scale and distribute.
Git fundamentally makes history a first-class immutable citizen, and
it's a major feature and a core design thing, and it's the _only_
thing that makes distribution possible. Whenever you rewrite history,
you fundamentally screw up a distributed model.
Linus
Powered by blists - more mailing lists