Confirmed users
1,927
edits
Bugzilla:Patches: Difference between revisions
Jump to navigation
Jump to search
no edit summary
(→Using diff: Say "bzr or CVS" and add .bzr to the --exclude) |
No edit summary |
||
| Line 1: | Line 1: | ||
After you've written your code, the next thing to do is to make a patch! This | After you've written your code, the next thing to do is to make a patch! This 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". | 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 source | |||
control. Basic usage is very similar to bzr, but there are different | |||
concepts and workflows. '''This is the preferred way of making patches.''' | |||
Git is very powerful, but anything beyond simple use is greatly aided | |||
by an understanding of the whole system. One of the best references is | |||
the book [http://git-scm.com/book Pro Git], which is available for | |||
free in its entirety. | |||
The following sections outline some simple workflows; for further | |||
details, see the Pro Git book or any of the numerous tutorials and | |||
references 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 diff is to just make local | |||
modifications and use '''git diff''' in that branch. This way should | |||
only be used if you’re making simple modifications to a couple files | |||
and 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 you | |||
really wanted to add them or if they are just left over from something | |||
else, 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 to | |||
tell git about any other changes you want to commit as well. Finally, | |||
you’ll have to add --cached to the '''git diff''' command. See the | |||
chapter 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 to | |||
work on more than one patch at a time, or if you just want to do | |||
things the typical git way, you’re going to want to create local | |||
branches for your work. | |||
After cloning, change to the branch you want to base your work | |||
on. 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 or | |||
fix-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 throw | |||
away, you don't need to be careful about crafting one tidy | |||
commit. Even if you have commit permissions and will be pushing your | |||
changes to the main git repository yourself, you can still squash | |||
commits together later via '''git rebase''' before merging into the | |||
base branch. | |||
Once you have completed your work, make sure all your changes are | |||
committed, then run | |||
git diff <base_branch> > patch.diff | |||
Replace ''base_branch'' by the name of the branch off of which your | |||
local branch is based, e.g. master, 4.4, 4.2, etc. This will produce a | |||
diff 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 that | |||
have been done upstream to your base branch by other developers--or | |||
even by yourself in another branch. This is out of scope for this simple | |||
tutorial, but see the chapter in Pro Git on | |||
[http://git-scm.com/book/en/Git-Branching branching] for lots more | |||
info, including details on standard git work flows. | |||
= Using Bzr = | = Using Bzr = | ||
If you [[Bugzilla:Bzr|checked Bugzilla out of bzr]], then you can make patches using bzr. | If you [[Bugzilla:Bzr|checked Bugzilla out of bzr]], then you can make patches using bzr. | ||
== The Simple Way: '''<code>bzr diff</code>''' == | == The Simple Way: '''<code>bzr diff</code>''' == | ||