git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH v3] request-pull: state what commit to expect

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 16, 2011, 19:04 UTC
Message-ID
<7viposfgvd.fsf_-_@alter.siamese.dyndns.org>
In-Reply-To
<7vobynui8a.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Show 15 quoted lines
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> I think that would probably be a good idea, although I'd actually
>> prefer you to be more verbose, and more human-friendly, and actually
>> talk about the commit in a readable way. Get rid of the *horrible*
>> BRANCH-NOT-VERIFIED message...
>>
>>  Top commit 1f51b001cccf: "Merge branches 'cns3xxx/fixes',
>>  'omap/fixes' and 'davinci/fixes' into fixes"
>>
>>  and at *that* point you might have a "UNVERIFIED" notice for people
>> to check if they forgot to push.
>
> That UNVERIFIED thing was neither my favorite nor my idea, and I'd happily
> rip it out in any second ;-)
So this is the third round.

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

A UI wart that we cannot fix without breaking backward compatibility is that the "end" parameter (which defaults to HEAD and is assigned to $head variable in the script) the requestor uses from the command line names a commit (often the name of a local branch), but for the purpose of telling which ref to pull from the public repository, that is a _wrong_ thing to give to the recipient.

Because the act of generating a request-pull message and the act of pushing to the public repository are not linked in any way, the script does not know _how_ the requestor caused (or intends to cause) the commit to sit at the tip of which branch. There is no guarantee that a lazy "git push" that relies on the configured refspec will be (or have been) used, so even parsing the output from "git push -n --porcelain -v $there" would not tell the script which branch the commit to be pulled is to be pushed out to, or if the branch is consistent with the request message.

The use of "git ls-remote" in the script and picking one of the refs that matches the commit object at random from its output is unsatisfactory, but that is unfortunately the best this script could do without correcting the design mistake and redefining what the "end" parameter means.

If we can break the backward compatibility and redefine that the "end" parameter now means the name of the branch at the public repository, it would make the operation a lot more robust. We could then:

 - $branch is what is given by the end user (it is an error not to give
   the "end" parameter);
 - run "git ls-remote $url $head" to find $headrev;
 - generate the message and shortlog using the information obtained from
   $url; and
 - get rid of "did you forget to push" message.

We could allow adding yet another argument which names a commit object locally, and make sure if the $headrev observed by ls-remote does not match it.

---
 git-request-pull.sh     |   34 +++++++++++++++++++---------------
 t/t5150-request-pull.sh |    6 ++++++
 2 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index afb75e8..438e7eb 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -35,7 +35,7 @@ do
 	shift
 done
 
-base=$1 url=$2 head=${3-HEAD}
+base=$1 url=$2 head=${3-HEAD} status=0
 
 test -n "$base" && test -n "$url" || usage
 baserev=$(git rev-parse --verify "$base"^0) &&
@@ -51,25 +51,29 @@ find_matching_branch="/^$headrev	"'refs\/heads\//{
 }'
 branch=$(git ls-remote "$url" | sed -n -e "$find_matching_branch")
 url=$(git ls-remote --get-url "$url")
-if test -z "$branch"
-then
-	echo "warn: No branch of $url is at:" >&2
-	git log --max-count=1 --pretty='tformat:warn:   %h: %s' $headrev >&2
-	echo "warn: Are you sure you pushed $head there?" >&2
-	echo >&2
-	echo >&2
-	branch=..BRANCH.NOT.VERIFIED..
-	status=1
-fi
 
 git show -s --format='The following changes since commit %H:
 
   %s (%ci)
 
-are available in the git repository at:' $baserev &&
-echo "  $url $branch" &&
-echo &&
+are available in the git repository at:
+' $baserev &&
+echo "  $url${branch+ $branch}" &&
+git show -s --format='
+for you to fetch changes up to %H:
+
+  %s (%ci)
+
+----------------------------------------------------------------' $headrev &&
 
 git shortlog ^$baserev $headrev &&
-git diff -M --stat --summary $patch $merge_base..$headrev || exit
+git diff -M --stat --summary $patch $merge_base..$headrev || status=1
+
+if test -z "$branch"
+then
+	echo "warn: No branch of $url is at:" >&2
+	git show -s --format='warn:   %h: %s' $headrev >&2
+	echo "warn: Are you sure you pushed '$head' there?" >&2
+	status=1
+fi
 exit $status
diff --git a/t/t5150-request-pull.sh b/t/t5150-request-pull.sh
index 9cc0a42..5bd1682 100755
--- a/t/t5150-request-pull.sh
+++ b/t/t5150-request-pull.sh
@@ -193,8 +193,14 @@ test_expect_success 'pull request format' '
 	  SUBJECT (DATE)
 
 	are available in the git repository at:
+
 	  URL BRANCH
 
+	for you to fetch changes up to OBJECT_NAME:
+
+	  SUBJECT (DATE)
+
+	----------------------------------------------------------------
 	SHORTLOG
 
 	DIFFSTAT
-- 
1.7.7.rc1.3.g559357
Previous: Sam VilainNext: Junio C Hamano
Message 35 of 62 in “[Survey] Signed push”
  1. Junio C HamanoSep 13, 2011
  2. 0/2 State commit name explicitly in request-pull messagesJunio C Hamano, Sep 13, 2011
  3. 1/2 fetch: allow asking for an explicit commit object by nameJunio C Hamano, Sep 13, 2011
  4. 2/2 request-pull: state exact commit object nameJunio C Hamano, Sep 13, 2011
  5. Guenter RoeckSep 13, 2011
  6. Junio C HamanoSep 13, 2011
  7. Junio C HamanoSep 14, 2011
  8. Sam VilainSep 14, 2011
  9. Shawn PearceSep 14, 2011
  10. Sam VilainSep 14, 2011
  11. Nguyen Thai Ngoc DuySep 14, 2011
  12. Jonathan NiederSep 14, 2011
  13. Nguyen Thai Ngoc DuySep 14, 2011
  14. Jeff KingSep 15, 2011
  15. Andy LutomirskiSep 14, 2011
  16. Junio C HamanoSep 14, 2011
  17. Andrew LutomirskiSep 14, 2011
  18. Fwd: [Survey] Signed pushLinus Torvalds, Sep 14, 2011
  19. Michael HaggertySep 14, 2011
  20. Matthieu MoySep 14, 2011
  21. Nguyen Thai Ngoc DuySep 14, 2011
  22. Johan HerlandSep 14, 2011
  23. Ted Ts'oSep 14, 2011
  24. Linus TorvaldsSep 14, 2011
  25. Matthieu MoySep 14, 2011
  26. Johan HerlandSep 14, 2011
  27. Philip OakleySep 14, 2011
  28. Linus TorvaldsSep 14, 2011
  29. Junio C HamanoSep 14, 2011
  30. Linus TorvaldsSep 14, 2011
  31. Junio C HamanoSep 14, 2011
  32. Linus TorvaldsSep 14, 2011
  33. Junio C HamanoSep 14, 2011
  34. Sam VilainSep 14, 2011
  35. request-pull: state what commit to expectJunio C Hamano, Sep 16, 2011
  36. Junio C HamanoSep 20, 2011
  37. 2/3 branch: teach --edit-description optionJunio C Hamano, Sep 20, 2011
  38. Andrew ArdillSep 21, 2011
  39. Junio C HamanoSep 21, 2011
  40. request-pull: use the branch descriptionJunio C Hamano, Sep 20, 2011
  41. 0/6 A handful of "branch description" patchesJunio C Hamano, Sep 22, 2011
  42. 1/6 branch: add read_branch_desc() helper functionJunio C Hamano, Sep 22, 2011
  43. 2/6 format-patch: use branch description in cover letterJunio C Hamano, Sep 22, 2011
  44. 3/6 branch: teach --edit-description optionJunio C Hamano, Sep 22, 2011
  45. Michael J GruberSep 23, 2011
  46. Nguyen Thai Ngoc DuySep 23, 2011
  47. Junio C HamanoSep 23, 2011
  48. Nguyen Thai Ngoc DuySep 25, 2011
  49. 4/6 request-pull: modernize styleJunio C Hamano, Sep 22, 2011
  50. 5/6 request-pull: state what commit to expectJunio C Hamano, Sep 22, 2011
  51. 6/6 request-pull: use the branch descriptionJunio C Hamano, Sep 22, 2011
  52. Michael J GruberSep 23, 2011
  53. Jeff KingSep 23, 2011
  54. Junio C HamanoSep 23, 2011
  55. Jeff KingSep 23, 2011
  56. Michael J GruberSep 24, 2011
  57. Jeff KingSep 27, 2011
  58. Annotated branch ≈ annotated tag?Michael Haggerty, Sep 28, 2011
  59. Andrew ArdillSep 28, 2011
  60. Michael HaggertySep 28, 2011
  61. Branch annotations [Re: Annotated branch ≈ annotated tag?]Michael J Gruber, Sep 28, 2011
  62. Jeff KingSep 29, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.