linux-kernel - Re: [PATCH RFC] Rough draft document on merging and rebasing

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]

Message-ID: <CAMuHMdWFdkzcFEsxVAzo17o1hVp6Z-3GftFcN6hDhg-ewX4M6g@mail.gmail.com>
Date:   Tue, 4 Jun 2019 12:29:33 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Jonathan Corbet <corbet@....net>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH RFC] Rough draft document on merging and rebasing

Hi Jon,

On Thu, May 30, 2019 at 9:54 PM Jonathan Corbet <corbet@....net> wrote:
> This is a first attempt at following through on last month's discussion
> about common merging and rebasing errors.  The hope here is to document
> existing best practices rather than trying to define new ones.  I've
> certainly failed somewhere along the way; please set me straight and I'll
> try to do better next time.
>
> Thanks,
>
> jon
>
> -------------
> docs: Add a document on repository management
>
> Every merge window seems to involve at least one episode where subsystem
> maintainers don't manage their trees as Linus would like.  Document the
> expectations so that at least he has something to point people to.
>
> Signed-off-by: Jonathan Corbet <corbet@....net>

Thanks!

> --- /dev/null
> +++ b/Documentation/maintainer/repo-hygiene.rst

> +One thing to be aware of in general is that, unlike many other projects,
> +the kernel community is not scared by seeing merge commits in its
> +development history.  Indeed, given the scale of the project, avoiding
> +merges would be nearly impossible.  Some problems encountered by
> +maintainers results from a desire to avoid merges, while others come from

result

> +merging a little too often.

[...]

> + - Realize the rebasing a patch series changes the environment in which it

Realize that

> +   was developed and, likely, invalidates much of the testing that was
> +   done.  A rebased patch series should, as a general rule, be treated like
> +   new code and retested from the beginning.

> +Finally
> +=======
> +
> +It is relatively common to merge with the mainline toward the beginning of
> +the development cycle in order to pick up changes and fixes done elsewhere
> +in the tree.  As always, such a merge should pick a well-known release
> +point rather than some random spot.  If your upstream-bound branch has
> +emptied entirely into the mainline during the merge window, you can pull it
> +forward with a command like::
> +
> +  git merge v5.2-rc1^0
> +
> +The "^0" will cause Git to do a fast-forward merge (which should be
> +possible in this situation), thus avoiding the addition of a spurious merge
> +commit.

I usually use

     git rebase v5.2-rc1 <mybranch>

_after_ verifying everything has been merged, i.e.

    git cherry -v v5.2-rc1 <mybranch>

did not give any output.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds