...
The code on which versioned releases are based is also available within the NuttX GIT repository clones or forks. Historical releases are identified with tags. For example, the tag nuttx-8.2 identifies the nuttx-8.2 release. A versioned branch could be created with the git command:
Code Block | ||
---|---|---|
| ||
git checkout -b <branch-name> nuttx-8.2 |
The code that you will find on the branch will differ from the the code in the versioned tarballs in two ways:
...
Cloning the Repositories: Clones of repositories are useful for creating patches that you can send to the Apache project for inclusion.
These are the steps to clone the repositories:
Code Block | ||||
---|---|---|---|---|
| ||||
git clone https://github.com/apache/incubator-nuttx nuttx |
...
git clone https://github.com/apache/incubator-nuttx-apps apps |
Create a separate branch for your work, this will facilitate creating patches and re-synchronizing with upstream.
...
Check the list of remotes that you have already:
Code Block language bash git remote -v
At this point only origin should exist:
Code Block origin https://github.com/<username>/incubator-nuttx.git (fetch)
...
origin https://github.com/<username>/incubator-nuttx.git (push)
Add the NuttX remote:
Code Block language bash linenumbers true git remote add upstream https://github.com/apache/incubator-nuttx.git
...
git remote -v
Now a new remote, named upstream, should show up:
Code Block origin https://github.com/<username>/incubator-nuttx.git (fetch)
...
origin https://github.com/<username>/incubator-nuttx.git (push)
...
upstream https://github.com/apache/incubator-nuttx.git (fetch)
...
upstream https://github.com/apache/incubator-nuttx.git (push)
Same as Similar to the clone workflow, create a separate branch for your work.
Code Block | ||||
---|---|---|---|---|
| ||||
git checkout master # If not already in master. git checkout -b <branch_name> # Create and switch to the branch. git push -u origin <branch_name> # Push the newly created branch to the fork and set it to track the remote branch. |
You can check the list of branches you have and what remote branches they are tracking with:
Code Block | ||
---|---|---|
| ||
git branch -vv |
...
This will output something similar to:
Code Block |
---|
master <commit_sha> [origin/master |
...
] <commit_msg> |
...
<branch_name> <commit_ |
...
sha> [origin/<branch_name> |
...
] <commit_msg> |
Committers Only. It is especially important that NuttX committers use forks rather than clones for code modification. Committers have write privileges directly into NuttX repositories and so also bear the responsibility of being especially careful not to accidentally make unauthorized modifications to the repositories. If committers use GIT clones of the NuttX repositories, then there is the constant risk of an error that inadvertently modifies the upstream repositories. When the committer functions as a contributor, this responsibility is best supported by using a safe fork rather than an uncontrolled clone.
...
When you are done developing and you are satisfied with your work, you can create a patch using this GIT command:
Code Block | ||
---|---|---|
| ||
git format-patch -<n> <sha> |
This will create a patch set based on the last number of commits <n> starting at the commit <sha>. Or
Code Block | ||
---|---|---|
| ||
git format-patch -<n> HEAD |
which will create a patch set starting at the HEAD of the branch. You can use git log --oneline origin/master..master | wc -l
to help you get the number of commits.
...
If you have changes on a separate branch, then you can use the following to create the patches.
Code Block | ||
---|---|---|
| ||
git format-patch master # Assuming the base branch is master. |
The generated patch set should be sent to dev@nuttx.apache.org. To make sure that your patch email is noticed, please start the subject line with [PATCH]
and a brief description. It is best to send the patch as an attachment with a .txt
extension, as that ensures it gets the correct MIME type and isn't blocked by the mailing list's spam filter.
...