Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 30 Aug 2021 02:26:44 +0300
From:   Kari Argillander <kari.argillander@gmail.com>
To:     Stephen Rothwell <sfr@canb.auug.org.au>
Cc:     Konstantin Komarov <almaz.alexandrovich@paragon-software.com>,
        ntfs3@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: Ntfs3 git repo in github should not back merge
Message-ID: <20210829232644.s2w3ggkyl2usmo55@kari-VirtualBox>
References: <20210825192746.ryi2vzn5gz4myxri@kari-VirtualBox>
 <20210830082308.649f2026@canb.auug.org.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210830082308.649f2026@canb.auug.org.au>
Precedence: bulk

On Mon, Aug 30, 2021 at 08:23:08AM +1000, Stephen Rothwell wrote:
> Hi Konstantin,
> 
> On Wed, 25 Aug 2021 22:27:46 +0300 Kari Argillander <kari.argillander@gmail.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.

I have a guestion also then. Right now situation is that there is
examaple missing Reviewed-by tags from commits. What should we do about
thouse? Or what to do if someone forget signed-off?

You also said earlier that rebasing is ok in this message:
https://lore.kernel.org/ntfs3/20210816063225.22d992ff@canb.auug.org.au/

I understand that rebasing should be avoided at almoust all cost, but
what are the screw ups that has to be fixed with it?

Thank you for answering and clarifying things.

> 
> > 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