Page History

...

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:

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:

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.

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:

git branch -vv

...

This will output something similar to:

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:

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

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.

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.

...