Page MenuHomeFreeBSD
Files F151190246

D30589.id90223.diff
No OneTemporary
Actions

D30589.id90223.diff
View Options

diff --git a/documentation/content/en/articles/committers-guide/_index.adoc b/documentation/content/en/articles/committers-guide/_index.adoc
--- a/documentation/content/en/articles/committers-guide/_index.adoc
+++ b/documentation/content/en/articles/committers-guide/_index.adoc
@@ -2209,6 +2209,82 @@
share the link with other collaborators.
+=== Landing a github pull request
+This section documents how to land a github pull request that's submitted against the FreeBSD git mirrors at github.
+While this is not an official way to submit patches at this time, sometimes good fixes come in this way and it is easiest just to bring them into a committer's tree and have them be commited from there.
+It is useful to have these steps documented for such situations.
+Similar steps can be used to pull branches from other repositories and land those.
+When pull requests from others, one should take extra care to examine all the changes to ensure they are exaclty as represented.
+
+Before you begin, make sure that your local Git repo is up to date and has the correct origins set <<keeping_current,as shown above.>>
+
+[source,shell]
+....
+% git remote -v
+freebsd https://git.freebsd.org/src.git (fetch)
+freebsd ssh://git@gitrepo.freebsd.org/src.git (push)
+....
+==== Setting up github remote
+Next, if you don't already have a github origin, you'll need to create one.
+These commands will only need to be done once.
+Future updates can be done with the `git fetch` command below.
+If you already have a github remote, you can spip the `git remote add` command and skip directly to the `git config` command.
+The rest of this section assumes it is created with `github` as its name, but you can use whatever name you like (just substitute it for githib below).
+As they are not part of the default refspec, one must also adjust the fetched refspec to grab the pull requests after creating the github origin.
+Once you've configured the origin and fetch refspec, grab it all from github.
+[source,shell]
+....
+% git remote -v
+freebsd https://git.freebsd.org/src.git (fetch)
+freebsd ssh://git@gitrepo.freebsd.org/src.git (push)
+% git remote add github git@github.com:freebsd/freebsd-src.git
+% git remove -v
+freebsd https://git.freebsd.org/src.git (fetch)
+freebsd ssh://git@gitrepo.freebsd.org/src.git (push)
+github git@github.com:freebsd/freebsd-src.git (fetch)
+github git@github.com:freebsd/freebsd-src.git (push)
+% git config --add remote.github.fetch "+refs/pull/*:refs/remotes/github/pull/*"
+% git fetch github
+....
+
+==== Merging a simple pull request
+Often pull requests are simple: requests that contains only a single commit.
+In this case, a streamlined approach may be used, though the approach in the prior section will also work.
+Here, we create a branch, cherry pick in the change, adjust the commit message, test and push the result.
+I use the branch `staging` but it can be any name.
+This can also work when there are multiple commits without conflict, though rebasing works better when there are, as outlined below.
+Briefly, this creates a branch; cherry-picks the changes from the pull request; tests it; adjusts the commit messages; and fast forward merges it back to `main`.
+[source,shell]
+....
+% git fetch github
+% git checkout main
+% git pull --ff-only # to get the latest
+% git checkout -b staging
+% git cherry-pick main..pull/github/123/head
+<do testing here, as needed>
+% git checkout main
+% git pull --ff-only # to get the latest if time has passed
+% git rebase -i main staging # to move the staging branch forward, adjust commit message here
+% git checkout main
+% git merge --ff-only staging
+<test again if needed>
+% git push
+....
+
+[.procedure]
+====
+For complicated pull requests, that have mutliple commits with conflicts, follow the following outline.
+
+. checkout the pull request `git checkout github/pull/XXX`
+. create a branch to rebase `git checkout -b staging`
+. rebase that `staging` to the latest `main` with `git rebase -i main staging`
+. resolve conflicts and do whatever testing is needed
+. merge the `staging` branch into `main` as above with
+. push as above
+
+This will also work when bringing branches developed elsewhere into your tree for committing.
+====
+
[[vcs-history]]
== Version Control History

File Metadata

Mime Type
text/plain
Expires
Tue, Apr 7, 5:23 PM (11 h, 12 s)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
31043565
Default Alt Text
D30589.id90223.diff (4 KB)

Event Timeline