From 1f010d6bdf756129db13d1367c888aa4153f6d87 Mon Sep 17 00:00:00 2001
From: "brian m. carlson" <sandals@crustytoothpaste.net>
Date: Mon, 20 Jan 2025 01:56:02 +0000
Subject: doc: use .adoc extension for AsciiDoc files

We presently use the ".txt" extension for our AsciiDoc files.  While not
wrong, most editors do not associate this extension with AsciiDoc,
meaning that contributors don't get automatic editor functionality that
could be useful, such as syntax highlighting and prose linting.

It is much more common to use the ".adoc" extension for AsciiDoc files,
since this helps editors automatically detect files and also allows
various forges to provide rich (HTML-like) rendering.  Let's do that
here, renaming all of the files and updating the includes where
relevant.  Adjust the various build scripts and makefiles to use the new
extension as well.

Note that this should not result in any user-visible changes to the
documentation.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/git-request-pull.adoc | 79 +++++++++++++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 Documentation/git-request-pull.adoc

(limited to 'Documentation/git-request-pull.adoc')

diff --git a/Documentation/git-request-pull.adoc b/Documentation/git-request-pull.adoc
new file mode 100644
index 0000000000..15dcbb6d91
--- /dev/null
+++ b/Documentation/git-request-pull.adoc
@@ -0,0 +1,79 @@
+git-request-pull(1)
+===================
+
+NAME
+----
+git-request-pull - Generates a summary of pending changes
+
+SYNOPSIS
+--------
+[verse]
+'git request-pull' [-p] <start> <URL> [<end>]
+
+DESCRIPTION
+-----------
+
+Generate a request asking your upstream project to pull changes into
+their tree.  The request, printed to the standard output,
+begins with the branch description, summarizes
+the changes, and indicates from where they can be pulled.
+
+The upstream project is expected to have the commit named by
+`<start>` and the output asks it to integrate the changes you made
+since that commit, up to the commit named by `<end>`, by visiting
+the repository named by `<URL>`.
+
+
+OPTIONS
+-------
+-p::
+	Include patch text in the output.
+
+<start>::
+	Commit to start at.  This names a commit that is already in
+	the upstream history.
+
+<URL>::
+	The repository URL to be pulled from.
+
+<end>::
+	Commit to end at (defaults to HEAD).  This names the commit
+	at the tip of the history you are asking to be pulled.
++
+When the repository named by `<URL>` has the commit at a tip of a
+ref that is different from the ref you have locally, you can use the
+`<local>:<remote>` syntax, to have its local name, a colon `:`, and
+its remote name.
+
+
+EXAMPLES
+--------
+
+Imagine that you built your work on your `master` branch on top of
+the `v1.0` release, and want it to be integrated into the project.
+First you push that change to your public repository for others to
+see:
+
+	git push https://git.ko.xz/project master
+
+Then, you run this command:
+
+	git request-pull v1.0 https://git.ko.xz/project master
+
+which will produce a request to the upstream, summarizing the
+changes between the `v1.0` release and your `master`, to pull it
+from your public repository.
+
+If you pushed your change to a branch whose name is different from
+the one you have locally, e.g.
+
+	git push https://git.ko.xz/project master:for-linus
+
+then you can ask that to be pulled with
+
+	git request-pull v1.0 https://git.ko.xz/project master:for-linus
+
+
+GIT
+---
+Part of the linkgit:git[1] suite
-- 
cgit v1.3

