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