os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Update vendor import with suggestions

Browse source 
Add git commit --amend with a comment about doing a final check of the commit
message before the push. Update with some more specific guidance on a good
commit message. Add link to commit message section. Minor tweaks I noticed
while doing this as well for having one setence one line.

Submitted by cy@
This commit is contained in:
Warner Losh 2021-03-17 11:15:57 -06:00
parent 8401b7bbb6
commit ad41defcd5
1 changed files with 17 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

33
documentation/content/en/articles/committers-guide/_index.adoc
View file

@ -719,7 +719,7 @@ use `git pull --rebase` and try to push again.
% for h in $HASH_LIST; do git cherry-pick -x $h; done % for h in $HASH_LIST; do git cherry-pick -x $h; done
% git rebase -i stable/X % git rebase -i stable/X
# mark each of the commits after the first as 'squash' # mark each of the commits after the first as 'squash'
# edit the commit message to be sane # edit the commit message to be sane, if necessary
% git push freebsd HEAD:stable/X % git push freebsd HEAD:stable/X
.... ....
@ -1100,10 +1100,8 @@ The cherry-pick can now be completed:
% git cherry-pick --continue % git cherry-pick --continue
.... ....
Since there was a merge conflict, Git invokes the editor to Since there was a merge conflict, Git invokes the editor to adjust the commit message.
adjust the commit message. Trim the metadata fields from the Trim the metadata fields from the commit log from the original commit to head and save the updated log message.
commit log from the original commit to head and save the
updated log message.
The contents of the MFC commit can be examined via `git show`: The contents of the MFC commit can be examined via `git show`:
@ -1228,11 +1226,10 @@ Note: I run the `git diff` and `git status` commands to make sure nothing weird
was present. Also I used `-m` to illustrate, but you should compose a proper was present. Also I used `-m` to illustrate, but you should compose a proper
message in an editor (using a commit message template). message in an editor (using a commit message template).
It is also important to create an annotated tag, otherwise the push It is also important to create an annotated tag, otherwise the push will be rejected.
will be rejected. Only annotated tags are allowed to be pushed. The Only annotated tags are allowed to be pushed.
annotated tag gives you a chance to enter a commit message. Enter The annotated tag gives you a chance to enter a commit message.
the version you are importing, along with any salient new features Enter the version you are importing, along with any salient new features or fixes in that version.
or fixes in that version.
==== Updating the FreeBSD Copy ==== Updating the FreeBSD Copy
At this point you can push the import to vendor into our repo. At this point you can push the import to vendor into our repo.
@ -1338,9 +1335,9 @@ At this point, you should have a pristine copy of glorbnitz ready to commit.
.... ....
% git commit -m"Import GlorbNitz frobnosticator revision 3.1415" % git commit -m"Import GlorbNitz frobnosticator revision 3.1415"
.... ....
As above, I used `-m` for simplicity, but you should likely create a As above, I used `-m` for simplicity, but you should likely create a commit message that explains what a Glorb is and why you'd use a Nitz to get it.
commit message that explains what a Glorb is and why you'd use a Nitz Not everybody will know.
to get it. Not everybody will know. But for your actual commmit, you should follow the <<commit-log-message,commit log message>> section instead of emulate the brief style here.
==== Now import it into our repository ==== Now import it into our repository
Now you need to import the branch into our repository. Now you need to import the branch into our repository.
@ -1372,6 +1369,7 @@ By 'good' we mean:
. None of the wrong files are present . None of the wrong files are present
. The vendor branch points at something sensible . The vendor branch points at something sensible
. The tag looks good, and is annotated. . The tag looks good, and is annotated.
. The commit message for the tag has a quick summary of what's new since the last tag
==== Time to finally merge it into the base tree ==== Time to finally merge it into the base tree
[source,shell] [source,shell]
@ -1379,17 +1377,20 @@ By 'good' we mean:
% cd ../src % cd ../src
% git subtree add -P contrib/glorbnitz vendor/glorbnitz % git subtree add -P contrib/glorbnitz vendor/glorbnitz
# Make sure the commit is good with "git show" # Make sure the commit is good with "git show"
% git commit --amend # one last sanity check on commit message
% git push freebsd % git push freebsd
.... ....
Here 'good' means: Here 'good' means:
. All the right files, and none of the wrong ones, were merged into contrib/glorbnitz. . All the right files, and none of the wrong ones, were merged into contrib/glorbnitz.
. No other changes are in the tree . No other changes are in the tree.
. The commit messages look good. . The commit messages look <<commit-log-message,good>>. It should contain a summary of what's changed since the last merge to the FreeBSD main line and any caveats.
. UPDATING should be updated if there is anything of note, such as user visible changes, important upgrade concerns, etc.
[NOTE] [NOTE]
==== ====
This hasn't connected `glorbnitz` to the build yet. How so do that is specific to the software being imported. This hasn't connected `glorbnitz` to the build yet.
How so do that is specific to the software being imported and is beyond the scope of this tutorial.
==== ====
=== FreeBSD Src Committer Transition Guide === FreeBSD Src Committer Transition Guide