[lkml]   [2019]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [GIT PULL] Thermal-SoC management fixes for v5.0-rc6
On Mon, Feb 11, 2019 at 12:16 PM Konstantin Ryabitsev
<> 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:// 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:// 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".


What git will do is

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

git matches against this list of patterns:


so "fixes" can match "refs/heads/fixes" and "refs/tags/fixes" (or
a *remote* called "fixes"), but it can never match against

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


 \ /
  Last update: 2019-02-11 23:04    [W:0.040 / U:3.400 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site