The whole point of the recent update to allow "git pull $url $tagname" is
so that the integrator does not have to store the (signed) tag that is
used to convey authenticity to be recorded in the resulting merge in the
local repository's tag namespace. Asking for a merge be made with "git
pull $url tag $tagname" defeats it.
Note that the request can become ambiguous if the requestor has a branch
with the same name as the tag, but that is not a new problem limited to
pulling. I wouldn't mind if somebody wants to add disambiguation to the
find_matching_ref logic in the script as a separate patch, though.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old code that insisted on asking for the tip of a branch to be pulled
were not updated when we started allowing for a tag to be pulled. When a
tag points at an older part of the history and there is no branch that
points at the tagged commit, the script failed to say which ref is to be
pulled.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The integrator tool will start allowing to pull a signed or an annotated
tag, i.e.
$ git pull $there tags/for-linus
and the description in the tag is used to convey a meaningful message from
the lieutenant to the integrator to justify the history being pulled.
Include the message in the pull request e-mail, as the same information is
useful in this context, too. It would encourage the lieutenants to write
meaningful messages in their signed tags.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The message gives a detailed explanation of the commit the requester based
the changes on, but lacks information that is necessary for the person who
performs a fetch & merge in order to verify that the correct branch was
fetched when responding to the pull request.
Add a few more lines to describe the commit at the tip expected to be
fetched to the same level of detail as the base commit.
Also update the warning message slightly when the script notices that the
commit may not have been pushed.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Solaris's xpg4/sed and IRIX's sed fail to parse these negated matching
expressions when the '!' is separated from the command that follows.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
10eb0007 (request-pull: avoid mentioning that the start point is a
single commit, 2010-01-29), changed the pull request format, so the
test needs some changes to still pass:
- tolerate a missing blank line between “in the git repository at:”
and the name of repository and branch
- recognize subject and date in the new request format
- update the expected request template to match the new format
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
At least /bin/sh on FreeBSD 8 interprets backslash followed by newline in an
unquoted here text as "empty".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Like most git commands, request-pull supports a -- delimiter to allow
callers to pass arguments that would otherwise be treated as an option
afterwards. The internal OPTIONS_KEEPDASHDASH variable is passed
empty to git-sh-setup to indicate that request-pull itself does not
care about the position of the -- delimiter. But if the user has
that variable in her environment, request-pull will see the “--” and
fail.
Empty it explicitly to guard against this. While at it, make the
corresponding fix to git-resurrect, too (all other scripts in git.git
already protect themselves).
Acked-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Test that request-pull handles failure to push cleanly, writes
pull requests that produce the correct effect when followed, and
uses a predictable format.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
