Backporting Changes

Bug fixes are typically cherry-picked from the development branch to each stable branch. Backporting can be done a number of ways.

Using Your Web Browser

If you have an account on Wireshark's code review system the easiest way by far to backport a change is to click the "Cherry Pick" button in the web interface and enter the destination branch (e.g. "master-2.0").

If cherry-picking didn't work (due to a merge conflict) or the change doesn't exist (because it predates our migration to Git) you will have to backport the change manually.

Using Git

If you want to propose a change for backporting, please cherry pick it and push it to HEAD:refs/for/master-1.10 or HEAD:refs/for/master-1.8 via Git at For example, to cherry-pick from master (SVN trunk) to master-1.10 (SVN trunk-1.10) you would do the following. We're assuming you have already cloned the Wireshark git repository and are in your local copy.

If you haven't created a local branch for the previous release you're going to back port to, you should do that first as follows:

Note that what the above "checkout -b" line does is create a local branch off of master called master-1.12. When you back-port to release 1.12, you'll be creating a branch off of the master-1.12 branch; when back-porting to release 1.10, you'll create a branch off of a master-1.10 branch; and so on.

Once you're in master-1.12, do the following:

If you encounter merge errors, see Development/SubmittingPatches for information on what to do. Note that you will have to amend your commit after fixing any errors.

If your editor opens a commit message page to edit for this, do not delete the existing Change-ID and Reviewer information. Keep that, but delete any Conflicts: lines, including the Conflicts: line itself. Once everything is ready you can upload your change to the server:

At this point Gerrit might complain about a missing Change ID. You can run

Add the same Change-ID as the original change you're backporting. Gerrit will know this is a new change and create a new review, because it's off of a different branch, but by keeping the same Change-ID gerrit shows it as part of the same change history.

To permanently avoid having to manually add the Change-ID, see gerrit change-ids.

At some future time after your pushed commit has been put into master-1.12 on, you can go back to your local master-1.12 branch, pull down from, rebase your backport branch, and then delete it. Note that git-review -f does this for you automatically.

Development/Backporting (last edited 2016-01-31 17:02:31 by JaapKeuter)