2010-06-02 08:13:41 +08:00
|
|
|
#!/bin/sh
|
2005-07-26 15:30:36 +08:00
|
|
|
# Copyright 2005, Ryan Anderson <ryan@michonline.com>
|
|
|
|
#
|
|
|
|
# This file is licensed under the GPL v2, or a later version
|
|
|
|
# at the discretion of Linus Torvalds.
|
|
|
|
|
2008-11-17 16:57:19 +08:00
|
|
|
USAGE='<start> <url> [<end>]'
|
|
|
|
LONG_USAGE='Summarizes the changes between two commits to the standard output,
|
|
|
|
and includes the given URL in the generated summary.'
|
2005-12-14 06:30:31 +08:00
|
|
|
SUBDIRECTORY_OK='Yes'
|
2010-04-24 20:15:37 +08:00
|
|
|
OPTIONS_KEEPDASHDASH=
|
2009-07-28 05:27:47 +08:00
|
|
|
OPTIONS_SPEC='git request-pull [options] start url [end]
|
|
|
|
--
|
|
|
|
p show patch text as well
|
|
|
|
'
|
|
|
|
|
2005-12-14 06:30:31 +08:00
|
|
|
. git-sh-setup
|
2005-07-26 15:30:36 +08:00
|
|
|
|
2009-07-01 17:40:30 +08:00
|
|
|
GIT_PAGER=
|
|
|
|
export GIT_PAGER
|
|
|
|
|
2009-07-28 05:27:47 +08:00
|
|
|
patch=
|
|
|
|
while case "$#" in 0) break ;; esac
|
|
|
|
do
|
|
|
|
case "$1" in
|
|
|
|
-p)
|
|
|
|
patch=-p ;;
|
|
|
|
--)
|
|
|
|
shift; break ;;
|
|
|
|
-*)
|
|
|
|
usage ;;
|
|
|
|
*)
|
|
|
|
break ;;
|
|
|
|
esac
|
|
|
|
shift
|
|
|
|
done
|
|
|
|
|
request-pull: more strictly match local/remote branches
The current 'request-pull' will try to find matching commit on the given
remote, and rewrite the "please pull" line to match that remote ref.
That may be very helpful if your local tree doesn't match the layout of
the remote branches, but for the common case it's been a recurring
disaster, when "request-pull" is done against a delayed remote update, and
it rewrites the target branch randomly to some other branch name that
happens to have the same expected SHA1 (or more commonly, leaves it
blank).
To avoid that recurring problem, this changes "git request-pull" so that
it matches the ref name to be pulled against the *local* repository, and
then warns if the remote repository does not have that exact same branch
or tag name and content.
This means that git request-pull will never rewrite the ref-name you gave
it. If the local branch name is "xyzzy", that is the only branch name
that request-pull will ask the other side to fetch.
If the remote has that branch under a different name, that's your problem
and git request-pull will not try to fix it up (but git request-pull will
warn about the fact that no exact matching branch is found, and you can
edit the end result to then have the remote name you want if it doesn't
match your local one).
The new "find local ref" code will also complain loudly if you give an
ambiguous refname (eg you have both a tag and a branch with that same
name, and you don't specify "heads/name" or "tags/name").
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-23 04:32:30 +08:00
|
|
|
base=$1 url=$2 status=0
|
2011-11-09 21:05:00 +08:00
|
|
|
|
2011-09-17 02:22:57 +08:00
|
|
|
test -n "$base" && test -n "$url" || usage
|
2013-07-18 01:28:11 +08:00
|
|
|
|
|
|
|
baserev=$(git rev-parse --verify --quiet "$base"^0)
|
|
|
|
if test -z "$baserev"
|
|
|
|
then
|
|
|
|
die "fatal: Not a valid revision: $base"
|
|
|
|
fi
|
|
|
|
|
request-pull: more strictly match local/remote branches
The current 'request-pull' will try to find matching commit on the given
remote, and rewrite the "please pull" line to match that remote ref.
That may be very helpful if your local tree doesn't match the layout of
the remote branches, but for the common case it's been a recurring
disaster, when "request-pull" is done against a delayed remote update, and
it rewrites the target branch randomly to some other branch name that
happens to have the same expected SHA1 (or more commonly, leaves it
blank).
To avoid that recurring problem, this changes "git request-pull" so that
it matches the ref name to be pulled against the *local* repository, and
then warns if the remote repository does not have that exact same branch
or tag name and content.
This means that git request-pull will never rewrite the ref-name you gave
it. If the local branch name is "xyzzy", that is the only branch name
that request-pull will ask the other side to fetch.
If the remote has that branch under a different name, that's your problem
and git request-pull will not try to fix it up (but git request-pull will
warn about the fact that no exact matching branch is found, and you can
edit the end result to then have the remote name you want if it doesn't
match your local one).
The new "find local ref" code will also complain loudly if you give an
ambiguous refname (eg you have both a tag and a branch with that same
name, and you don't specify "heads/name" or "tags/name").
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-23 04:32:30 +08:00
|
|
|
#
|
|
|
|
# $3 must be a symbolic ref, a unique ref, or
|
2014-01-23 07:23:48 +08:00
|
|
|
# a SHA object expression. It can also be of
|
|
|
|
# the format 'local-name:remote-name'.
|
request-pull: more strictly match local/remote branches
The current 'request-pull' will try to find matching commit on the given
remote, and rewrite the "please pull" line to match that remote ref.
That may be very helpful if your local tree doesn't match the layout of
the remote branches, but for the common case it's been a recurring
disaster, when "request-pull" is done against a delayed remote update, and
it rewrites the target branch randomly to some other branch name that
happens to have the same expected SHA1 (or more commonly, leaves it
blank).
To avoid that recurring problem, this changes "git request-pull" so that
it matches the ref name to be pulled against the *local* repository, and
then warns if the remote repository does not have that exact same branch
or tag name and content.
This means that git request-pull will never rewrite the ref-name you gave
it. If the local branch name is "xyzzy", that is the only branch name
that request-pull will ask the other side to fetch.
If the remote has that branch under a different name, that's your problem
and git request-pull will not try to fix it up (but git request-pull will
warn about the fact that no exact matching branch is found, and you can
edit the end result to then have the remote name you want if it doesn't
match your local one).
The new "find local ref" code will also complain loudly if you give an
ambiguous refname (eg you have both a tag and a branch with that same
name, and you don't specify "heads/name" or "tags/name").
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-23 04:32:30 +08:00
|
|
|
#
|
2014-01-23 07:23:48 +08:00
|
|
|
local=${3%:*}
|
|
|
|
local=${local:-HEAD}
|
|
|
|
remote=${3#*:}
|
|
|
|
head=$(git symbolic-ref -q "$local")
|
|
|
|
head=${head:-$(git show-ref --heads --tags "$local" | cut -d' ' -f2)}
|
|
|
|
head=${head:-$(git rev-parse --quiet --verify "$local")}
|
request-pull: more strictly match local/remote branches
The current 'request-pull' will try to find matching commit on the given
remote, and rewrite the "please pull" line to match that remote ref.
That may be very helpful if your local tree doesn't match the layout of
the remote branches, but for the common case it's been a recurring
disaster, when "request-pull" is done against a delayed remote update, and
it rewrites the target branch randomly to some other branch name that
happens to have the same expected SHA1 (or more commonly, leaves it
blank).
To avoid that recurring problem, this changes "git request-pull" so that
it matches the ref name to be pulled against the *local* repository, and
then warns if the remote repository does not have that exact same branch
or tag name and content.
This means that git request-pull will never rewrite the ref-name you gave
it. If the local branch name is "xyzzy", that is the only branch name
that request-pull will ask the other side to fetch.
If the remote has that branch under a different name, that's your problem
and git request-pull will not try to fix it up (but git request-pull will
warn about the fact that no exact matching branch is found, and you can
edit the end result to then have the remote name you want if it doesn't
match your local one).
The new "find local ref" code will also complain loudly if you give an
ambiguous refname (eg you have both a tag and a branch with that same
name, and you don't specify "heads/name" or "tags/name").
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-23 04:32:30 +08:00
|
|
|
|
|
|
|
# None of the above? Bad.
|
2014-01-23 07:23:48 +08:00
|
|
|
test -z "$head" && die "fatal: Not a valid revision: $local"
|
request-pull: more strictly match local/remote branches
The current 'request-pull' will try to find matching commit on the given
remote, and rewrite the "please pull" line to match that remote ref.
That may be very helpful if your local tree doesn't match the layout of
the remote branches, but for the common case it's been a recurring
disaster, when "request-pull" is done against a delayed remote update, and
it rewrites the target branch randomly to some other branch name that
happens to have the same expected SHA1 (or more commonly, leaves it
blank).
To avoid that recurring problem, this changes "git request-pull" so that
it matches the ref name to be pulled against the *local* repository, and
then warns if the remote repository does not have that exact same branch
or tag name and content.
This means that git request-pull will never rewrite the ref-name you gave
it. If the local branch name is "xyzzy", that is the only branch name
that request-pull will ask the other side to fetch.
If the remote has that branch under a different name, that's your problem
and git request-pull will not try to fix it up (but git request-pull will
warn about the fact that no exact matching branch is found, and you can
edit the end result to then have the remote name you want if it doesn't
match your local one).
The new "find local ref" code will also complain loudly if you give an
ambiguous refname (eg you have both a tag and a branch with that same
name, and you don't specify "heads/name" or "tags/name").
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-23 04:32:30 +08:00
|
|
|
|
|
|
|
# This also verifies that the resulting head is unique:
|
|
|
|
# "git show-ref" could have shown multiple matching refs..
|
2013-07-18 01:28:11 +08:00
|
|
|
headrev=$(git rev-parse --verify --quiet "$head"^0)
|
2014-01-23 07:23:48 +08:00
|
|
|
test -z "$headrev" && die "fatal: Ambiguous revision: $local"
|
request-pull: more strictly match local/remote branches
The current 'request-pull' will try to find matching commit on the given
remote, and rewrite the "please pull" line to match that remote ref.
That may be very helpful if your local tree doesn't match the layout of
the remote branches, but for the common case it's been a recurring
disaster, when "request-pull" is done against a delayed remote update, and
it rewrites the target branch randomly to some other branch name that
happens to have the same expected SHA1 (or more commonly, leaves it
blank).
To avoid that recurring problem, this changes "git request-pull" so that
it matches the ref name to be pulled against the *local* repository, and
then warns if the remote repository does not have that exact same branch
or tag name and content.
This means that git request-pull will never rewrite the ref-name you gave
it. If the local branch name is "xyzzy", that is the only branch name
that request-pull will ask the other side to fetch.
If the remote has that branch under a different name, that's your problem
and git request-pull will not try to fix it up (but git request-pull will
warn about the fact that no exact matching branch is found, and you can
edit the end result to then have the remote name you want if it doesn't
match your local one).
The new "find local ref" code will also complain loudly if you give an
ambiguous refname (eg you have both a tag and a branch with that same
name, and you don't specify "heads/name" or "tags/name").
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-23 04:32:30 +08:00
|
|
|
|
|
|
|
# Was it a branch with a description?
|
|
|
|
branch_name=${head#refs/heads/}
|
|
|
|
if test "z$branch_name" = "z$headref" ||
|
|
|
|
! git config "branch.$branch_name.description" >/dev/null
|
2013-07-18 01:28:11 +08:00
|
|
|
then
|
request-pull: more strictly match local/remote branches
The current 'request-pull' will try to find matching commit on the given
remote, and rewrite the "please pull" line to match that remote ref.
That may be very helpful if your local tree doesn't match the layout of
the remote branches, but for the common case it's been a recurring
disaster, when "request-pull" is done against a delayed remote update, and
it rewrites the target branch randomly to some other branch name that
happens to have the same expected SHA1 (or more commonly, leaves it
blank).
To avoid that recurring problem, this changes "git request-pull" so that
it matches the ref name to be pulled against the *local* repository, and
then warns if the remote repository does not have that exact same branch
or tag name and content.
This means that git request-pull will never rewrite the ref-name you gave
it. If the local branch name is "xyzzy", that is the only branch name
that request-pull will ask the other side to fetch.
If the remote has that branch under a different name, that's your problem
and git request-pull will not try to fix it up (but git request-pull will
warn about the fact that no exact matching branch is found, and you can
edit the end result to then have the remote name you want if it doesn't
match your local one).
The new "find local ref" code will also complain loudly if you give an
ambiguous refname (eg you have both a tag and a branch with that same
name, and you don't specify "heads/name" or "tags/name").
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-23 04:32:30 +08:00
|
|
|
branch_name=
|
2013-07-18 01:28:11 +08:00
|
|
|
fi
|
2005-07-26 15:30:36 +08:00
|
|
|
|
2011-09-17 02:22:57 +08:00
|
|
|
merge_base=$(git merge-base $baserev $headrev) ||
|
2007-05-01 14:08:23 +08:00
|
|
|
die "fatal: No commits in common between $base and $head"
|
|
|
|
|
request-pull: more strictly match local/remote branches
The current 'request-pull' will try to find matching commit on the given
remote, and rewrite the "please pull" line to match that remote ref.
That may be very helpful if your local tree doesn't match the layout of
the remote branches, but for the common case it's been a recurring
disaster, when "request-pull" is done against a delayed remote update, and
it rewrites the target branch randomly to some other branch name that
happens to have the same expected SHA1 (or more commonly, leaves it
blank).
To avoid that recurring problem, this changes "git request-pull" so that
it matches the ref name to be pulled against the *local* repository, and
then warns if the remote repository does not have that exact same branch
or tag name and content.
This means that git request-pull will never rewrite the ref-name you gave
it. If the local branch name is "xyzzy", that is the only branch name
that request-pull will ask the other side to fetch.
If the remote has that branch under a different name, that's your problem
and git request-pull will not try to fix it up (but git request-pull will
warn about the fact that no exact matching branch is found, and you can
edit the end result to then have the remote name you want if it doesn't
match your local one).
The new "find local ref" code will also complain loudly if you give an
ambiguous refname (eg you have both a tag and a branch with that same
name, and you don't specify "heads/name" or "tags/name").
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-23 04:32:30 +08:00
|
|
|
# $head is the refname from the command line.
|
|
|
|
# If a ref with the same name as $head exists at the remote
|
|
|
|
# and their values match, use that.
|
2012-06-02 03:38:19 +08:00
|
|
|
#
|
|
|
|
# Otherwise find a random ref that matches $headrev.
|
2011-12-17 01:00:11 +08:00
|
|
|
find_matching_ref='
|
2014-01-23 07:23:48 +08:00
|
|
|
my ($head,$headrev) = (@ARGV);
|
|
|
|
my ($found);
|
|
|
|
|
2011-12-17 01:00:11 +08:00
|
|
|
while (<STDIN>) {
|
2014-01-23 07:23:48 +08:00
|
|
|
chomp;
|
request-pull: more strictly match local/remote branches
The current 'request-pull' will try to find matching commit on the given
remote, and rewrite the "please pull" line to match that remote ref.
That may be very helpful if your local tree doesn't match the layout of
the remote branches, but for the common case it's been a recurring
disaster, when "request-pull" is done against a delayed remote update, and
it rewrites the target branch randomly to some other branch name that
happens to have the same expected SHA1 (or more commonly, leaves it
blank).
To avoid that recurring problem, this changes "git request-pull" so that
it matches the ref name to be pulled against the *local* repository, and
then warns if the remote repository does not have that exact same branch
or tag name and content.
This means that git request-pull will never rewrite the ref-name you gave
it. If the local branch name is "xyzzy", that is the only branch name
that request-pull will ask the other side to fetch.
If the remote has that branch under a different name, that's your problem
and git request-pull will not try to fix it up (but git request-pull will
warn about the fact that no exact matching branch is found, and you can
edit the end result to then have the remote name you want if it doesn't
match your local one).
The new "find local ref" code will also complain loudly if you give an
ambiguous refname (eg you have both a tag and a branch with that same
name, and you don't specify "heads/name" or "tags/name").
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-23 04:32:30 +08:00
|
|
|
my ($sha1, $ref, $deref) = /^(\S+)\s+([^^]+)(\S*)$/;
|
2014-01-23 07:23:48 +08:00
|
|
|
my ($pattern);
|
|
|
|
next unless ($sha1 eq $headrev);
|
|
|
|
|
|
|
|
$pattern="/$head\$";
|
|
|
|
if ($ref eq $head) {
|
|
|
|
$found = $ref;
|
|
|
|
}
|
|
|
|
if ($ref =~ /$pattern/) {
|
|
|
|
$found = $ref;
|
2012-06-02 03:38:19 +08:00
|
|
|
}
|
2014-01-23 07:23:48 +08:00
|
|
|
if ($sha1 eq $head) {
|
request-pull: more strictly match local/remote branches
The current 'request-pull' will try to find matching commit on the given
remote, and rewrite the "please pull" line to match that remote ref.
That may be very helpful if your local tree doesn't match the layout of
the remote branches, but for the common case it's been a recurring
disaster, when "request-pull" is done against a delayed remote update, and
it rewrites the target branch randomly to some other branch name that
happens to have the same expected SHA1 (or more commonly, leaves it
blank).
To avoid that recurring problem, this changes "git request-pull" so that
it matches the ref name to be pulled against the *local* repository, and
then warns if the remote repository does not have that exact same branch
or tag name and content.
This means that git request-pull will never rewrite the ref-name you gave
it. If the local branch name is "xyzzy", that is the only branch name
that request-pull will ask the other side to fetch.
If the remote has that branch under a different name, that's your problem
and git request-pull will not try to fix it up (but git request-pull will
warn about the fact that no exact matching branch is found, and you can
edit the end result to then have the remote name you want if it doesn't
match your local one).
The new "find local ref" code will also complain loudly if you give an
ambiguous refname (eg you have both a tag and a branch with that same
name, and you don't specify "heads/name" or "tags/name").
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-23 04:32:30 +08:00
|
|
|
$found = $sha1;
|
2011-12-17 01:00:11 +08:00
|
|
|
}
|
|
|
|
}
|
2014-01-23 07:23:48 +08:00
|
|
|
if ($found) {
|
2011-12-17 01:00:11 +08:00
|
|
|
print "$found\n";
|
|
|
|
}
|
|
|
|
'
|
|
|
|
|
2014-01-23 07:23:48 +08:00
|
|
|
ref=$(git ls-remote "$url" | @@PERL@@ -e "$find_matching_ref" "${remote:-HEAD}" "$headrev")
|
request-pull: more strictly match local/remote branches
The current 'request-pull' will try to find matching commit on the given
remote, and rewrite the "please pull" line to match that remote ref.
That may be very helpful if your local tree doesn't match the layout of
the remote branches, but for the common case it's been a recurring
disaster, when "request-pull" is done against a delayed remote update, and
it rewrites the target branch randomly to some other branch name that
happens to have the same expected SHA1 (or more commonly, leaves it
blank).
To avoid that recurring problem, this changes "git request-pull" so that
it matches the ref name to be pulled against the *local* repository, and
then warns if the remote repository does not have that exact same branch
or tag name and content.
This means that git request-pull will never rewrite the ref-name you gave
it. If the local branch name is "xyzzy", that is the only branch name
that request-pull will ask the other side to fetch.
If the remote has that branch under a different name, that's your problem
and git request-pull will not try to fix it up (but git request-pull will
warn about the fact that no exact matching branch is found, and you can
edit the end result to then have the remote name you want if it doesn't
match your local one).
The new "find local ref" code will also complain loudly if you give an
ambiguous refname (eg you have both a tag and a branch with that same
name, and you don't specify "heads/name" or "tags/name").
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-23 04:32:30 +08:00
|
|
|
|
|
|
|
if test -z "$ref"
|
|
|
|
then
|
2014-01-23 07:23:48 +08:00
|
|
|
echo "warn: No match for commit $headrev found at $url" >&2
|
|
|
|
echo "warn: Are you sure you pushed '${remote:-HEAD}' there?" >&2
|
request-pull: more strictly match local/remote branches
The current 'request-pull' will try to find matching commit on the given
remote, and rewrite the "please pull" line to match that remote ref.
That may be very helpful if your local tree doesn't match the layout of
the remote branches, but for the common case it's been a recurring
disaster, when "request-pull" is done against a delayed remote update, and
it rewrites the target branch randomly to some other branch name that
happens to have the same expected SHA1 (or more commonly, leaves it
blank).
To avoid that recurring problem, this changes "git request-pull" so that
it matches the ref name to be pulled against the *local* repository, and
then warns if the remote repository does not have that exact same branch
or tag name and content.
This means that git request-pull will never rewrite the ref-name you gave
it. If the local branch name is "xyzzy", that is the only branch name
that request-pull will ask the other side to fetch.
If the remote has that branch under a different name, that's your problem
and git request-pull will not try to fix it up (but git request-pull will
warn about the fact that no exact matching branch is found, and you can
edit the end result to then have the remote name you want if it doesn't
match your local one).
The new "find local ref" code will also complain loudly if you give an
ambiguous refname (eg you have both a tag and a branch with that same
name, and you don't specify "heads/name" or "tags/name").
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-23 04:32:30 +08:00
|
|
|
status=1
|
|
|
|
fi
|
2011-12-17 01:00:11 +08:00
|
|
|
|
2011-03-01 17:21:37 +08:00
|
|
|
url=$(git ls-remote --get-url "$url")
|
2007-05-01 14:08:23 +08:00
|
|
|
|
2010-01-29 22:17:59 +08:00
|
|
|
git show -s --format='The following changes since commit %H:
|
2005-07-26 15:30:36 +08:00
|
|
|
|
2010-01-29 22:17:59 +08:00
|
|
|
%s (%ci)
|
|
|
|
|
2011-09-17 02:37:08 +08:00
|
|
|
are available in the git repository at:
|
2012-01-11 13:45:52 +08:00
|
|
|
' $merge_base &&
|
2014-01-23 07:23:48 +08:00
|
|
|
echo " $url $remote" &&
|
2011-09-17 02:37:08 +08:00
|
|
|
git show -s --format='
|
|
|
|
for you to fetch changes up to %H:
|
|
|
|
|
|
|
|
%s (%ci)
|
|
|
|
|
|
|
|
----------------------------------------------------------------' $headrev &&
|
2005-07-26 15:30:36 +08:00
|
|
|
|
2011-09-21 06:52:57 +08:00
|
|
|
if test -n "$branch_name"
|
|
|
|
then
|
2011-12-17 01:00:11 +08:00
|
|
|
echo "(from the branch description for $branch_name local branch)"
|
2011-09-21 06:52:57 +08:00
|
|
|
echo
|
|
|
|
git config "branch.$branch_name.description"
|
|
|
|
echo "----------------------------------------------------------------"
|
|
|
|
fi &&
|
2011-11-09 21:05:00 +08:00
|
|
|
|
2010-06-02 08:13:41 +08:00
|
|
|
git shortlog ^$baserev $headrev &&
|
2011-09-17 02:37:08 +08:00
|
|
|
git diff -M --stat --summary $patch $merge_base..$headrev || status=1
|
|
|
|
|
2007-05-01 14:08:23 +08:00
|
|
|
exit $status
|