linux-kernel - Re: [GIT PULL] per signal

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] [day] [month] [year] [list]

Date:   Thu, 18 Nov 2021 01:29:08 -0800
From:   Junio C Hamano <gitster@...ox.com>
To:     Junio C Hamano <junio@...ox.com>
Cc:     ebiederm@...ssion.com (Eric W. Biederman),
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Git List Mailing <git@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Oleg Nesterov <oleg@...hat.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Kees Cook <keescook@...omium.org>,
        Linux API <linux-api@...r.kernel.org>
Subject: Re: [GIT PULL] per signal_struct coredumps

Junio C Hamano <junio@...ox.com> writes:

>                               Y--- (Linus's tree)
>                              / Linus pulls from subsystem maintainer
>       \   \       \   \     /
>     ---x---x---M---x---x---N (Subsystem maintainer's tree)
>               /           /
>              /           /
>   ...---o---o---p---p---p (Your tree)
>
> The above picture only depicts two topics, one directly building on
> top of the other, from you, but that is simplified merely for
> illustration purposes.  The real history may have more topics, some
> are dependent on others, while some are independent.
>
> Now, if you have many related but more or less independent topic
> branches that will support a larger theme, it would be quite natural
> if you acted as your own "subsystem" maintainer, in other words, in
> ...
> and offer 'N' as the tip of a "larger" topic that has internal
> structure, not just a single strand of pearls, by adding a signed
> tag on 'N' and throwing a pull request at Linus (or whoever is
> immediately above your level).
> 
> Is that what happened (as I said, I lack context)?  If so, I do not
> see much problem in the situation.  But this assumes that these so
> called "fake" merges are merging into right first parents.

Addendum.

If you have only one topic (i.e. you do not have o-o and p-p-p in
the above picture, but just o-o), then it would be quite strange to
create M and offer it to the upstream, as M's first parent, as well
as the bottom of the o-o chain, would be something the upstream has
and the merge would look redundant from upstream's point of view, as
they will be creating another merge of their tip and M, at which
point they'd rather merge the topmost commit in the o-o chain
directly without having to deal with M.