Re: Re* [RFC PATCH 2/1] Make request-pull able to take a refspec of form local:remote

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jan 30, 2014, 00:40 UTC
Message-ID: <CA+55aFyWM+VDa4mdqseNy3tSnp23x=2sPtHf5KpxsfROeHbVGw@mail.gmail.com>
In-Reply-To: <xmqqfvo6icqf.fsf_-_@gitster.dls.corp.google.com>

On Wed, Jan 29, 2014 at 3:34 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 5 quoted lines

>
> I am not yet doing the docs, but here is a minimal (and I think is
> the most sensible) fix to the "If I asked a tag to be pulled, I used
> to get the message from the tag in the output---the updated code no
> longer does so" problem.

That was a complete oversight/bug on my part, due to just removing the tag_name special cases, not thinking about the tag message.

Thinking some more about the tag_name issue, I realize that the other patch ("Make request-pull able to take a refspec of form local:remote") broke another thing.

The first patch pretty-printed the local branch-name, removing "refs/" and possibly "heads/" from the local refname. So for a branch, it would ask people to just pull from the branch-name, and for a tag it would ask people to pull from "tags/name", which is good policy. So if you had a tag called "for-linus", it would say so (using "tags/for-linus").

But the local:remote syntax thing ends up breaking that nice feature. The old find_matching_refs would actually cause us to show the "tags" part if it existed on the remote, but that had become pointless and counter-productive with the first patch. But with the second patch, maybe we should reinstate that logic..

                Linus