Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190210041721.GA2805@localhost.localdomain> <154977271617.2362.11794417398216386913.pr-tracker-bot@kernel.org>
 <20190211031921.GA1799@localhost.localdomain> <CAHk-=wgz_WpD7jc084QROuM0zszEG0-WvQhQZPsCboMOWNRiWw@mail.gmail.com>
 <20190211201619.GA8065@work>
In-Reply-To: <20190211201619.GA8065@work>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon, 11 Feb 2019 14:04:08 -0800
Message-ID: <CAHk-=wg9yvP3hGVRSnc=8qoj0g7_zt=_2FjmgSAu-0DViyFtaw@mail.gmail.com>
Subject: Re: [GIT PULL] Thermal-SoC management fixes for v5.0-rc6
To:     Linus Torvalds <torvalds@linux-foundation.org>,
        Eduardo Valentin <edubezval@gmail.com>,
        pr-tracker-bot@kernel.org, Rui Zhang <rui.zhang@intel.com>,
        ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
        Linux PM <linux-pm@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Feb 11, 2019 at 12:16 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> 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:

No, you don't do even that.

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

> $ 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^{}

*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