On Thu, Nov 19, 2020 at 01:43:38PM +0100, Linus Walleij wrote: > On Thu, Nov 19, 2020 at 11:57 AM Andy Shevchenko > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > > > > And that patch was on my fixes branch, which went into v5.10-rc4, > > > so in order to have the base commit in the devel tree I had to merge > > > in v5.10-rc4. > > > > I based solely on your gpio/for-next as has been stated in the cover letter. > > So, the PR might have been applied on top of your gpio/for-next without any > > additional merge required. > > OK but my for-next isn't what is going to be merged by Torvalds so there > is some misunderstanding here. > > In my tree "for-next" does not mean "for the next kernel that Torvalds > is going to release", it means "for the linux-next integration tree". > > What is going into v5.11 is "devel" and that is why I'm always talking > about pulling stuff into devel etc. > > for-next is created when I merged a few patches like this: > > > git checkout for-next > > git reset --hard fixes > > git merge devel > > (Procedure to create integration branch recommended by > Stephen Rothwell at one point.) > > This is why your pull request work fine anyways if I merge in -rc4 > because then "devel" will contain all commits from these two > branches at that point. > > > I admit that PR automatic text is a bit deviated (it has been taken from wrong > > base, note that tag is correct nevertheless). I will look forward to amend my > > scripts. > > Don't worry about it. > > Maybe I need to think about how I name stuff. > > Should I rename the branch "for-next" to "for-sjr-next" and > rename "devel" to "for-torvalds-next" then "fixes" > into "for-torvalds-current" or something > so it is crystal clear what they are for? > > The community doesn't really have an established standard > here. Hmm... Usually for-next is what should come as material for next cycle. And devel or so is for testing (can be rebased / etc) I like the following schema (with possible variations in the parentheses): fixes (for-current) - what is going to the next rc of current cycle for-next - what is going to the next release cycle devel (review, ...) - what is under review / testing / etc What you explained to me seems like swapped for-next and devel semantics and this is confusing because the above schema is what I met in 99% of repositories I'm cooking patches against. -- With Best Regards, Andy Shevchenko