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