Thermal-SoC management fixes for v5.0-rc6

Hello Linus,

Please consider pulling from

git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal fixes

to receive Thermal-SoC Management fixes for v5.0-rc6 with top-most

bf78f133cd39e0ed41551150909e41513958a738:

thermal: cpu_cooling: Clarify error message (2019-02-05 15:50:13 -0800)

on top of commit 8834f5600cf3c8db365e18a3d5cac2c2780c81e5:

Linux 5.0-rc5 (2019-02-03 13:48:04 -0800)

Specifics:
- Minor fixes on of-thermal and cpu cooling.

BR,
Eduardo

----------------------------------------------------------------
Amit Kucheria (2):
thermal: of-thermal: Print name of device node with error
thermal: cpu_cooling: Clarify error message

 drivers/thermal/cpu_cooling.c | 2 +-
 drivers/thermal/of-thermal.c  | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

Hey,

Thanks for the note, but..

I think the bot is off here because the above commit is about a merge from the linux-omap tree from Tony.

7ad915f5ebf5 ("Merge tag 'omap-for-v3.10-rc1/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes")

not the above pull. In fact, this pull was not merged so far, as per the log of v5.0-rc6. I mean, this is a very late fixes pull anyways and I can always resend the pull, but I believe the bot got confused this time.

Indeed.

.. and the pr-tracker-bot thing actually made me ignore the pull request, thinking I had left it in my inbox despite having pulled it.

So it would be really good to know why pr-tracker-bot ended up replying to the wrong email, because it can cause real problems.

Linus

Simply put, it's because "it's a pull request sent to Linus." We currently don't disambiguate between Linus showing up in "To" or in "Cc" -- is that an important differentiation that should be enforced?

-K

Linus:

Sorry, I totally misunderstood what you were saying -- I blame the jet lag. I'll check out what's going on.

-K

Okay, so I need guidance on the proper behaviour here. As this request didn't use the magic wording for the commit-id (as generated by git-request-pull), we ended up trying to look up the remote. The remote specified was:

git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal fixes

Since it's a short refname, we first try to look it up as a tag:

$ git ls-remote git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal fixes^{}
a6d25f4c951b8b28f2eaec6f891ff834622532f2        refs/tags/omap-for-v3.10-rc1/fixes^{}
77319669af37a1cfc844b801e83343b37e3c7e13        refs/tags/omap/fixes^{}

If it finds a matching tag, the script assumes you'd meant to specify the tag, not the head. Is that the opposite of git's behaviour when applying a remote? Should we be checking for a head first, before we try the refname as a tag? I assume that's the case, but want to double-check with you all.

-K

No, you don't do even that.

The name is "fixes". But you seem to match it with one of these:

*NEITHER* of which is a tag named "fixes". One is named "omap-for-v3.10-rc1/fixes" and the other is a tag named "omap/fixes".

Notice?

What git will do is

(a) Never *ever* match against a partial name.

     git matches against this list of patterns:

        "%.*s",
        "refs/%.*s",
        "refs/tags/%.*s",
        "refs/heads/%.*s",
        "refs/remotes/%.*s",
        "refs/remotes/%.*s/HEAD",

     so "fixes" can match "refs/heads/fixes" and "refs/tags/fixes" (or

a *remote* called "fixes"), but it can never match against "refs/tags/omap/fixes".

(b) If you have an actual ambiguous name, git will indeed pick the
first from that list (so tags before branches, but also HEAD before a tag called HEAD), but it will generally also warn:

warning: refname 'xyz' is ambiguous.

So using "ls-remote" the way you are actually gives *way* more matches than it should. The ls-remote pattern is really just a grep pattern, not an actual ref lookup.

So if you want to look up tag 'x', you really need to match on 'refs/tags/x' exactly.

But that does explain why you thought it matched.

Anyway, the _real_ merge for that pull request has now happened, and is commit aa0c38cf39de.

Linus

Linus:

Thank you for the feedback. I've implemented a fix that handles shortname refs more properly in order to avoid hitting this problem again.

Regards,
-K