On Tue, Sep 26, 2017 at 08:13:49AM +0300, Leon Romanovsky wrote: > On Mon, Sep 25, 2017 at 10:31:47PM -0400, Doug Ledford wrote: > > On 9/25/2017 11:57 AM, Leon Romanovsky wrote: > > > On Mon, Sep 25, 2017 at 10:53:01AM -0400, Doug Ledford wrote: > > >> On 9/24/2017 11:59 PM, Leon Romanovsky wrote: > > >>> On Sat, Sep 23, 2017 at 11:03:25AM -0400, Doug Ledford wrote: > > >>> > > >>> <...> > > >>> > > >>>> > > >>>> I want any shared pull requests to be based on nothing newer than an > > >>>> rc2 kernel. I branch my for-next branch at rc2, so if your pull > > >>>> request is on something later it will pollute my main for-next branch > > >>>> to merge it. I plan to merge my own -rc pull requests after rc2 into > > >>>> my for-next branch, so you won't be missing code that goes into later > > >>>> rcs if you base your work on my for-next branch, so that's a second > > >>>> alternative starting point for your shared pull requests should you > > >>>> need it. > > >>> > > >>> From our experience, it is not feasible to demand shared pull > > >>> requests on "newer than an rc2 kernel". > > >> > > >> I said "nothing newer than an rc2 kernel". Did you mean to leave out > > >> the nothing? > > > > > > Most probably I translated it incorrectly. I wanted to say that all > > > shared pull requests will be -rc2, -rc3, e.t.c. and probably will never > > > be -rc1. Did you mean the same? > > > > > >> > > >>> The magic of shared pull request > > >>> is in the fact that it is based on the same origin for both trees. > > >> > > >> Correct. So, for instance, I'm opening up my for-next area today and it > > >> will be based on a clean v4.14-rc2. What I'm then asking for is that > > >> subsequent driver shared pull requests be based on a v4.14-rc2 tree. > > >> Your last shared pull request was mostly OK, but it was based on a > > >> v4.13-rc4 kernel and so it would have simultaneously brought in your > > >> patches and also all the changes between 4.13-rc2 and 4.13-rc4. > > > > > > Why is it "undesired behavior"? Anyhow git request-pull to Linus will > > > filter all patches which already exist in Linus's tree and you will get > > > merge of -rc fixes for free in your for-next. > > > > You obviously have not been paying attention when Linus yells at me. > > I do, but probably we are understanding Linus's responses differently. > > You probably mean the conversation after that pull request. > * First round of RC fixes for 4.13 > https://marc.info/?l=linux-rdma&m=150039306716272&w=2 > > He started to complain about empty merge commit with v4.13-rc1, and continued with explanations > about difference between back and forward merges. From my point of view, my intention to base > shared pull request on latest -rcX is exactly forward (good) merge, because it ensures that > all our future submissions for net/net-next/rdma-rc/rdma-next are completely in sync and > ready to go. And if we are talking about back-forward merges, the following merge is a back one and it was mentioned by Linus as a bad type of merge which should be avoided: * Merge tag 'v4.14-rc2' into k.o/for-next https://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git/commit/?h=k.o/for-next&id=0d9c2ff1c9f7f8b339fc42ac9763b28c71f1c115 Because your previous for-next was fully merged and new one was opened after -rc2 and your initial pull request with fixes was accepted during in -rc1 too, you was supposed simply reset your for-next to v4.14-rc2 tag git reset --hard v4.14-rc2) as a starting point of for-next. Thanks > > > This is something he specifically does *not* want, and if you send me a > > shared pull request that is based on, say, -rc4, then I can't merge it > > into my for-next branch and instead of I have to carry a separate branch > > and send a separate pull request just for that branch. > > I don't think so, but we can probably catch Linus at KS next month and > ask him directly. > > > > > The reason is that Linus wants to be able to pull up gitk on my pull > > request and see the changes I am submitting for easy review. If I merge > > a shared pull request that also includes an update to the -rc level of > > my tree, then all those -rc patches get mixed into the gitk ordering and > > it makes it hard for Linus to find just the patches he wants. So, this > > is a Linus issue, not so much my issue. If he didn't care, I wouldn't > > either, but this is the way it is. > > > > I don't know how gitk presents git history, but the following command > "git log --graph --no-merges -- drivers/infiniband include/rdma/ include/uapi/rdma" works like > a charm and presents only RDMA related commits. > > Other replies from Linus about late submission, compiler warnings, tree-wide changes, > request to separate pull requests, fix with strange name ("Add ...") are completely unrelated. > > I read upto 19 Mar 2016, in that pull request Linus explained to us how we should create shared pull request. > Everything before is not relevant for shared pull requests. > > Thanks > > > > > -- > > Doug Ledford <dledford@xxxxxxxxxx> > > GPG Key ID: B826A3330E572FDD > > Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD > > > > >
Attachment:
signature.asc
Description: PGP signature
