linux-kernel - Re: Ntfs3 git repo in github should not back merge

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: <20210830082308.649f2026@canb.auug.org.au>
Date:   Mon, 30 Aug 2021 08:23:08 +1000
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     Konstantin Komarov <almaz.alexandrovich@...agon-software.com>
Cc:     Kari Argillander <kari.argillander@...il.com>,
        ntfs3@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: Ntfs3 git repo in github should not back merge

Hi Konstantin,

On Wed, 25 Aug 2021 22:27:46 +0300 Kari Argillander <kari.argillander@...il.com> wrote:
>
> I notice that you have made back-merge in ntfs3 git repo in github.
> This should not be done without good reason and there is none in this
> case. If there is reason you should also write good merge commit for it.

This is correct, but in this case with an initial submission, Linus is
likely to be a bit easier on you.  Just explain that you realise that
you probably should not have done the back merge.  Also, if you are
going to merge another branch you should not use the github web
interface to do it.  It does not allow you to produce a useful commit
message for the merge commit.  Linus has expressed this recently about
another tree that is maintained on github (unfortunately in a private
message, so it is not archived anywhere).

> Here is link which you can read about back-merges. If you have any
> questions you can always ask.
> 
> 01.org/linuxgraphics/gfx-docs/drm/maintainer/rebasing-and-merging.html#merging-from-sibling-or-upstream-trees

Also available in the kernel tree at Documentation/maintainer/...

> You could also go check some other trees how they do it. Usually there
> is next/master/main/for-next which will be repo which will contain stuff
> for next-merge window. This is usually based on rc1, rc2, rc3 depending
> when you put first patches to next merge window. As you based your
> branch top of the rc5.

Again with an initial submission this should not be a problem.  And, in
any case, varies among maintainer quite a bit.  But -rc1/2 is usually a
good place to start your next round of development.

> Because your master branch is  for next you could have rebased your
> branch top of the rc7 if you want to but that is kinda pointless. You
> could always fix little mistakes in next branch with rebase, but you
> should propably info this action to ntfs3 mailing list.

Do *not* rebase a published branch except in exceptional circumstances.
All branches included in linux-next should be considered published.

> The idea is that this repo has very clean history always when it get
> merged to Linus tree. Also developers who work with ntfs3 can see
> everything in one eye.
> 
> Example take a look Ext4 dev (for-next) branch
> https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/log/?h=dev
> You see that this is based on rc2. Theodore will create pull-request
> based on this when he creates pull-request. Very clean history and no
> back-merges.

Also no rebasing (that I can remember).

-- 
Cheers,
Stephen Rothwell

Content of type "application/pgp-signature" skipped