Re: [PATCH 0/3] request-pull: do something if $3 is passed

From: Paolo Bonzini <bonzini@gnu.org>
Date: Feb 17, 2015, 10:12 UTC
Message-ID: <54E31405.5040502@gnu.org>
In-Reply-To: <xmqqiof163kk.fsf@gitster.dls.corp.google.com>

On 16/02/2015 20:47, Junio C Hamano wrote:

Show 12 quoted lines

> Paolo Bonzini <bonzini@gnu.org> writes:
> 
>> From: Paolo Bonzini <pbonzini@redhat.com>
>>
>> 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.

Show 5 quoted lines

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

Show 6 quoted lines

> 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