Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > This resulted in a case[1] where someone on LKML did: > > git push kvm +HEAD:tags/for-linus > > Which would have created a new "refs/heads/tags/for-linus" branch in > their "kvm" repository. But since they happened to have an existing > "refs/tags/for-linus" reference we pushed there instead, and replaced > an annotated tag with a lightweight tag. I do not think that is a problematic behaviour in the context of asking Linus to pull when every time a merge window opens. One would keep refs/tags/for-linus at the publishing site, and update it (forcing as necessary) before request-pull. If it went to a branch with confusing name tags/for-linus, that would be a disaster. > Now we'll print out the following advice when this happens, and act > differently as described therein: > > hint: The <dst> part of the refspec matched both of: > hint: > hint: 1. tags/my-tag -> refs/tags/my-tag > hint: 2. tags/my-tag -> refs/heads/tags/my-tag > hint: > hint: Earlier versions of git would have picked (1) as the RHS starts > hint: with a second-level ref prefix which could be fully-qualified by > hint: adding 'refs/' in front of it. We now pick (2) which uses the prefix > hint: inferred from the <src> part of the refspec. > hint: > hint: See the "<refspec>..." rules discussed in 'git help push'. "matched" in past tense means that your example scenario actually has such a confusing branch? Then I think the above is OK (or just silently updating the branch is also fine, I think). If there were no such branch currently, the above woudl be a serious regression, but as long as both exist, I think it is probably OK. From my quick scan of your new tests, I couldn't quite tell if that case (i.e. the a tag "my-tag" exists but a bbranch "tags/my-tag"does not exist at the receiving end when push happens, and the tag is updated without touching the branch nor giving extra warnings and hints) is covered, though. Thanks.
