Message ID | 20201116152625.GA20187@black.fi.intel.com |
---|---|
State | New |
Headers | show |
Series | [GIT,PULL] intel-gpio for 5.11-1 | expand |
On Mon, Nov 16, 2020 at 4:26 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > The following changes since commit b72de3ff19fdc4bbe4d4bb3f4483c7e46e00bac3: > > gpio: sifive: Fix SiFive gpio probe (2020-11-11 09:53:09 +0100) > > are available in the Git repository at: > > git@gitolite.kernel.org:pub/scm/linux/kernel/git/andy/linux-gpio-intel.git tags/intel-gpio-v5.11-1 > > for you to fetch changes up to e709a7b5a066362b697d65dda90edc71f913df70: > > gpiolib: acpi: Make Intel GPIO tree official for GPIO ACPI work (2020-11-16 14:14:35 +0200) Thanks! I merged in v5.10-rc4 to the GPIO devel branch and pulled in this on top, works like a charm! Yours, Linus Walleij
On Tue, Nov 17, 2020 at 10:24:37PM +0100, Linus Walleij wrote: > On Mon, Nov 16, 2020 at 4:26 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > > The following changes since commit b72de3ff19fdc4bbe4d4bb3f4483c7e46e00bac3: > > > > gpio: sifive: Fix SiFive gpio probe (2020-11-11 09:53:09 +0100) > > > > are available in the Git repository at: > > > > git@gitolite.kernel.org:pub/scm/linux/kernel/git/andy/linux-gpio-intel.git tags/intel-gpio-v5.11-1 > > > > for you to fetch changes up to e709a7b5a066362b697d65dda90edc71f913df70: > > > > gpiolib: acpi: Make Intel GPIO tree official for GPIO ACPI work (2020-11-16 14:14:35 +0200) > > Thanks! I merged in v5.10-rc4 to the GPIO devel branch and > pulled in this on top, works like a charm! I'm not sure I understood why you merged v5.10-rc4, but in any case thanks, result is great!
On Wed, Nov 18, 2020 at 3:17 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > On Tue, Nov 17, 2020 at 10:24:37PM +0100, Linus Walleij wrote: > > Thanks! I merged in v5.10-rc4 to the GPIO devel branch and > > pulled in this on top, works like a charm! > > I'm not sure I understood why you merged v5.10-rc4, but in any case thanks, > result is great! I merged v5.10-rc4 because the pull request says: > The following changes since commit b72de3ff19fdc4bbe4d4bb3f4483c7e46e00bac3: > > gpio: sifive: Fix SiFive gpio probe (2020-11-11 09:53:09 +0100) 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. Yours, Linus Walleij
On Thu, Nov 19, 2020 at 09:31:03AM +0100, Linus Walleij wrote: > On Wed, Nov 18, 2020 at 3:17 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > On Tue, Nov 17, 2020 at 10:24:37PM +0100, Linus Walleij wrote: > > > > Thanks! I merged in v5.10-rc4 to the GPIO devel branch and > > > pulled in this on top, works like a charm! > > > > I'm not sure I understood why you merged v5.10-rc4, but in any case thanks, > > result is great! > > I merged v5.10-rc4 because the pull request says: > > > The following changes since commit b72de3ff19fdc4bbe4d4bb3f4483c7e46e00bac3: > > > > gpio: sifive: Fix SiFive gpio probe (2020-11-11 09:53:09 +0100) > > 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. 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.
On Thu, Nov 19, 2020 at 12:58:28PM +0200, Andy Shevchenko wrote: > On Thu, Nov 19, 2020 at 09:31:03AM +0100, Linus Walleij wrote: > > On Wed, Nov 18, 2020 at 3:17 PM Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: > > > On Tue, Nov 17, 2020 at 10:24:37PM +0100, Linus Walleij wrote: > > > > > > Thanks! I merged in v5.10-rc4 to the GPIO devel branch and > > > > pulled in this on top, works like a charm! > > > > > > I'm not sure I understood why you merged v5.10-rc4, but in any case thanks, > > > result is great! > > > > I merged v5.10-rc4 because the pull request says: > > > > > The following changes since commit b72de3ff19fdc4bbe4d4bb3f4483c7e46e00bac3: > > > > > > gpio: sifive: Fix SiFive gpio probe (2020-11-11 09:53:09 +0100) > > > > 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. > > 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 "information in the tag" > scripts.
On Thu, Nov 19, 2020 at 11:57 AM Andy Shevchenko <andriy.shevchenko@linux.intel.com> 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. Yours, Linus Walleij
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@linux.intel.com> 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.