@ -18,7 +18,7 @@ The following workflow is recommended by Evan and is the guideline for contribut
3.
Create a branch for your work. This will make a copy of the current branch (master) and name it "new_feature". Now you can work in this new branch without breaking the main one.
Create a branch for your work. This will make a copy of the current branch (main) and name it "new_feature". Now you can work in this new branch without breaking the main one.
git checkout -b new_feature
@ -30,9 +30,9 @@ The following workflow is recommended by Evan and is the guideline for contribut
5.
When you are ready to send your local changes back to the Rubinius repository, you first need to ensure that your local copy is up-to-date. First, ensure you have committed your local changes. Then switch from your topic branch to the master branch.
When you are ready to send your local changes back to the Rubinius repository, you first need to ensure that your local copy is up-to-date. First, ensure you have committed your local changes. Then switch from your topic branch to the main branch.
git checkout master
git checkout main
6.
@ -45,11 +45,11 @@ The following workflow is recommended by Evan and is the guideline for contribut
Switch back to your topic branch and integrate any new changes. The git rebase command will save your changes away, update the topic branch, and then reapply them.
git checkout new_feature
git rebase master
git rebase main
Warning! If you are sharing a branch, you must use:
git merge master
git merge main
Rebase causes the commit layout to change and will confuse anyone you've shared this branch with.
@ -61,9 +61,9 @@ The following workflow is recommended by Evan and is the guideline for contribut
9.
Now, switch back to the master branch and merge your changes from the topic branch
Now, switch back to the main branch and merge your changes from the topic branch
git checkout master
git checkout main
git merge new_feature
10.
@ -84,7 +84,7 @@ The following workflow is recommended by Evan and is the guideline for contribut
git branch -d new_feature
When you're familiar with the workflow, you can use the rake tasks to help you out. For example, rake git will fetch the latest code from remote repo, rebase the current branch to master, fast-forward the changes to master and push the commits to the remote. This saves a lot of typing. Check rake -T git for all the git related tasks.
When you're familiar with the workflow, you can use the rake tasks to help you out. For example, rake git will fetch the latest code from remote repo, rebase the current branch to main, fast-forward the changes to main and push the commits to the remote. This saves a lot of typing. Check rake -T git for all the git related tasks.
Taken from: http://rubinius.lighthouseapp.com/projects/5089/using-git
@ -15,7 +15,7 @@ There are a few ways of testing Suricata:
- **Static and dynamic analysis tools**: to help in finding bugs, memory leaks and other issues (like `scan-build <https://clang-analyzer.llvm.org/scan-build.html#scanbuild_basicusage>`_, from `clang`, which is also used for our C formatting checks; or ASAN, which checks for memory issues);
- **Fuzz testing**: especially good for uncovering existing, often non-trivial bugs. For more on how to fuzz test Suricata, check :doc:`fuzz-testing`;
- **CI checks**: each PR submitted to the project's public repositories will be run against a suit of Continuous Integration
workflows, as part of our QA process. Those cover: formatting and commit checks; fuzz tests (CI Fuzz), and several builds. See our `github workflows <https://github.com/OISF/suricata/tree/master/.github/workflows>`_ for details and those in
workflows, as part of our QA process. Those cover: formatting and commit checks; fuzz tests (CI Fuzz), and several builds. See our `github workflows <https://github.com/OISF/suricata/tree/main/.github/workflows>`_ for details and those in
action at `<https://github.com/OISF/suricata/actions>`_.
..note:: If you can run unit tests or other checks and report failures in our `issue tracker <https://redmine.openinfosecfoundation.org/projects/suricata/issues>`_, that is rather useful and appreciated!
@ -40,7 +40,7 @@ given that the way to do so differs, depending on the language.
Code Examples
^^^^^^^^^^^^^
An example from the `DNS parser <https://github.com/OISF/suricata/blob/master/rust/src/dns/parser.rs#L417>`_. This
An example from the `DNS parser <https://github.com/OISF/suricata/blob/main/rust/src/dns/parser.rs#L417>`_. This
checks that the given raw input (note the comments indicating what it means), once processed by ``dns_parse_name`` yields
the expected result, including the unparsed portion.
@ -71,7 +71,7 @@ Though the steps are the same, there are a few differences when implementing fra
Rust
----
This section shows how Frame support is added in Rust, using examples from the `SIP parser <https://github.com/OISF/suricata/blob/master/rust/src/sip/sip.rs>`_, and the `telnet parser <https://github.com/OISF/suricata/blob/master/rust/src/telnet/telnet.rs>`_.
This section shows how Frame support is added in Rust, using examples from the `SIP parser <https://github.com/OISF/suricata/blob/main/rust/src/sip/sip.rs>`_, and the `telnet parser <https://github.com/OISF/suricata/blob/main/rust/src/telnet/telnet.rs>`_.
**Define the frame types**. The frame types are defined as an enum. In Rust, make sure to derive from the ``AppLayerFrameType``:
Victor Julien
9 months ago