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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxx/ 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
