Ntfs3 git repo in github should not back merge

[Kari Argillander]

Hello Konstantin.

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.
As you are just coming to maintener I will write little info about how
this stuff works. I'm not maintainer, but I have study about how kernel
is maintained.

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

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.

https://git.kernel.org/?s=idle

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.

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.

If you wonder how should you do development then if you can't back
merge. You should do develompent in linux-next branch. This way you
always know if others break something reletad to ntfs3. Then you check
who was it and send email about it and you solve it together. It can be
tricky some times who will take which patches but help is given if you
ask.

There is lot of small info what I did not include here and hopefully
everything is correct. Hopefully you will also in near future respond
patches which are sent to you. There is already quite lot. If you need
any help how to maintainer should handle those I can assisntant you best
I can. There will be example little bit work howto make all fixes tags
right because you will have to rebase your current commits as they do
not have example reviewed-tags.

I also CC linux-next maintainer as he knows this stuff and can say if I
say something wrong. And I feel like new maintainer can have little help
from gurus.

Kari Argillander