Page MenuHomeFreeBSD
Files F108366683

D30589.diff
No OneTemporary
Actions

D30589.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
@@ -2208,6 +2208,60 @@
At this point your work is now in your branch on +GitHub+ and you can
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 pushed into the FreeBSD's tree from there.
+Similar steps can be used to pull branches from other repositories and land those.
+When committing pull requests from others, one should take extra care to examine all the changes to ensure they are exactly as represented.
+
+Before beginning, make sure that the local Git repo is up to date and has the correct origins set <<keeping_current,as shown above.>>
+In addition, make sure to have the following origins:
+[source,shell]
+....
+% git remote -v
+freebsd https://git.freebsd.org/src.git (fetch)
+freebsd ssh://git@gitrepo.freebsd.org/src.git (push)
+github https://github.com/freebsd/freebsd-src (fetch)
+github https://github.com/freebsd/freebsd-src (fetch)
+....
+Often pull requests are simple: requests that contain only a single commit.
+In this case, a streamlined approach may be used, though the approach in the prior section will also work.
+Here, a branch is created, the change is cherry picked, the commit message adjusted, and sanity-checked before being pushed.
+The branch `staging` is used in this example but it can be any name.
+This technique works for any number of commits in the pull request, especailly when the changes apply cleanly to the FreeBSD tree.
+However, when there's multiple commits, especially when minor adjustments are needed, `git rebase -i` works better than `git cherry-pick`.
+Briefly, these commands create a branch; cherry-picks the changes from the pull request; tests it; adjusts the commit messages; and fast forward merges it back to `main`.
+The PR number is `$PR` below.
+When adjusting the message, add `Pull Request: https://github.com/freebsd-src/pull/$PR`.
+[source,shell]
+....
+% git fetch github pull/$PR/head:staging
+% git rebase -i main staging # to move the staging branch forward, adjust commit message here
+<do testing here, as needed>
+% git checkout main
+% git pull --ff-only # to get the latest if time has passed
+% git checkout main
+% git merge --ff-only staging
+<test again if needed>
+% git push freebsd
+....
+
+[.procedure]
+====
+For complicated pull requests that have multiple 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 the `staging` branch to the latest `main` with `git rebase -i main staging`
+. resolve conflicts and do whatever testing is needed
+. fast forward the `staging` branch into `main` as above
+. final sanity check of changes to make sure all is well
+. push to FreeBSD's Git repository.
+
+This will also work when bringing branches developed elsewhere into the local tree for committing.
+====
+Once finished with the pull request, close it using GitHub's web interface.
+If the changes are fetched with https, this last step is the only one requiring a GitHub account.
[[vcs-history]]
== Version Control History

File Metadata

Mime Type
text/plain
Expires
Sat, Jan 25, 5:06 AM (20 h, 42 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
16125445
Default Alt Text
D30589.diff (3 KB)

Event Timeline