On 16/02/2015 20:47, Junio C Hamano wrote: > Paolo Bonzini <bonzini@xxxxxxx> writes: > >> From: Paolo Bonzini <pbonzini@xxxxxxxxxx> >> >> After updating to git 2.3.0, "git request-pull" is stubbornly complaining >> that I lack a matching tag on the remote side unless I pass the third >> argument. But I did prepare and push a signed tag. > > A few questions. > > - what old version did you update from? I think the "correct > over-eager dwimming" change was from v2.0 days. I upgraded from 1.9. My workflow is to make a signed tag, push it and do "git request-pull origin/master <url>". My branches have a different name locally vs. remotely (e.g. "kvm-master" and "kvm-next" locally vs. refs/heads/master and refs/heads/next remotely) exactly to avoid overeager matching in git-request-pull. I only ever want to request pulls based on signed tags. > - what exactly do you mean by "stubbornly complain"? I think we > say something about HEAD not matching the HEAD over there, which > I think is bogus (we should instead say things about the branch > you are on and the branch over there with the same name) and is > worth fixing. I tried both "git checkout kvm-next" and "git checkout tags/for-linus", and it still complains. What you refer to is, I think, fixed by patch 3. The find_matching_ref script does not work if its first argument is HEAD. So patch 3 is probably an improvement anyway for the "matching branch name" case, even if my usecase involves tags rather than branches. > An earlier 024d34cb (request-pull: more strictly match local/remote > branches, 2014-01-22) deliberately disabled over-eager DWIMming when > the $3-rd argument _is_ given. I agree with that change. > One part of me feel that not giving the $3-rd argument should behave > the same way as if you gave the name of the current branch as the > $3-rd argument. This works well for workflows where you do pull requests based on branches. However Linus strongly encourages using signed tags. I certainly can adjust my workflow for this. For example I can add something like this to my .gitconfig [request-pull] dwim = tags/for-linus and add an alias that uses "git config request-pull.dwim" as the third argument (other projects I work on obviously use different tag names :). While similar, the two patches are different: 1) The usage of "git show-ref --heads --tags" looked like a feeble attempt at DWIMming tags. But I can see how that is supposed to work only if $3 is specified. Adding a usage of "git tag --points-at" would go against the intentions of 024d34cb. Perhaps restrict DWIMming to signed and annotated tags only, through a new option to "git tag"? 2) Patch 3 makes sense independent of patch 2 and, as mentioned above, it is probably a bugfix anyway. > On the other hand, I can also understand (not necessarily agree > with) a view that not giving the $3-rd argument is an explicit > user's wish to us to DWIM as much as we want. But again, that > directly contradicts with the desire of 024d34cb. > > So,... I dunno. I don't know either. Based on your answer, it seems like you are focusing mostly on a branch-based workflow; the two definitely have different requirements for DWIMming (since you cannot get a tag name via "git symbolic-ref" for example). On the other hand most of the un-DWIMming changes were done by Linus who works a lot with (other people's) signed tags... Paolo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html