On Wed, Jan 29, 2014 at 3:34 PM, Junio C Hamano <gits...@pobox.com> wrote:
>
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
