Changes

After you've written your code, the next thing to do is to make a patch! This is a file that page will show exactly what changes you made to Bugzilla or its documentation, in a format that we can review and integrate into our codebase.

We also call patches "diffs", because one program used for making patches is called "diff”. = Using git = We are transitioning to [[Bugzilla:Git|git]] for our sourcecontrol. Basic usage is very similar to bzr, but there are differentconcepts and workflows. '''This is the preferred way of making patches.''' Git is very powerful, but anything beyond simple use is greatly aidedby an understanding of the whole system. One of the best references isthe book [http://git-scm.com/book Pro Git], which is available forfree in its entirety. The following sections outline some simple workflows; for furtherdetails, see the Pro Git book or any of the numerous tutorials andreferences available online. == The Simple Way: Local uncommitted changes == After cloning the Bugzilla repo and switching to your desired branch,the simplest way to generate a diffis to just make localmodifications and use '''git diff''' in that branch. This way shouldonly be used if you’re making simple modifications to a couple filesand only working on one patch at a time. If you’ve only modified or removed existing files, then this is all you need:  git diff > patch.diff This will not catch any new files, since git doesn’t know if youreally wanted to add them or if they are just left over from somethingelse, e.g. building. If you want new files included in your patch,then you need to run '''git add''' on them. However, in this case,you’ll ''also'' have to run '''git add''' on any ''modified'' files and'''git rm''' on any deleted files. This is because once you’ve"staged" changes to be committed (added your new files), you have totell git about any other changes you want to commit as well. Finally,you’ll have to add --cached to the '''git diff''' command. See thechapter of Pro Git on[http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository recording changes to the git repository] for more details. You can then upload "patch.diff" as your patch. == The Better Way: Local development branches == If you are intending to do any complicated changes, or if you want towork on more than one patch at a time, or if you just want to dothings the typical git way, you’re going to want to create localbranches for your work. After cloning, change to the branch you want to base your workon. Create and switch to a new, local branch by running  git checkout -b <branch_name> Replace ''branch_name'' by something descriptive, e.g. bug-123456 orfix-headers. You might want to include the base branch name as well,particularly if you are doing the same fix to multiple branches. At this point, you can add, modify, and remove files ''and commit as often as you like''. Because git branches are cheap and easy to throwaway, you don't need to be careful about crafting one tidycommit. Even if you have commit permissions and will be pushing yourchanges to the main git repository yourself, you can still squashcommits together later via '''git rebase''' before merging into thebase branch. Once you have completed your work, make sure all your changes arecommitted, then run  git diff <base_branch> > patch.diff Replace ''base_branch'' by the name of the branch off of which yourlocal branch is based, e.g. master, 4.4, 4.2, etc. This will produce adiff of all changes you committed since you branched; upload"patch.diff" as your patch. You can even "rebase"your local branch to update it with changes thathave been done upstream to your base branch by other developers--oreven by yourself in another branch. This is out of scope for this simpletutorial, but see the chapter in Pro Git on[http://git-scm.com/book/en/Git-Branching branching] for lots moreinfo, including details on standard git work flows.

If you [[Bugzilla:Bzr|checked Bugzilla out of bzr]], then you can make patches using bzr. '''This is the preferred way of making patches.'''