The content on this page is partially outdated: GNOME has moved from git.gnome.org to gitlab.gnome.org. gitlab.gnome.org has a workflow with merge requests, see Git/Developers. Creating diffs (as covered below) is not needed anymore.

How To Submit Patches

Quick run-down of things that will make it more likely that your patch is accepted, and with minimum delay (in addition to the Apps/Dia/CodingGuidelines:

• Don't try to solve multiple problems in one patch -- not only will it make us reject the whole patch if one of the problems is poorly solved, it also makes it harder for us to evaluate what is solved by a particular change.

• In particular, don't try to clean up indentation, comments or the like.  This will just make it harder for us to read.  If you want to clean stuff up, do it in a separate patch.

• Post the patch as an attachment to the appropriate bug report or your mail.  This will ensure that vital spaces are retained.

• Your patch is less likely to be forgotten if put in a bug report rather than a mail, as those can be efficiently searched for.
• Make sure you base your patch off of the latest version of the public repository, if possible.
• Describing roughly how you solve the problem will make it easier to evaluate the patch.

The best way to generate patches is to clone the public repository (the command is git clone git://git.gnome.org/dia my_working_copy unless you work in a graphical environment).  This is possible, of course, not only on Linux/Unix, but also on Windows with Cygwin, as well as on MacOS X.

Then see the documentation of git for git add, git commit, git format-patch, among others.

An alternative is to have two copies, up to date with the main repository of course, one pristine (let's call it dia-pristine) and one work area (let's call it dia-workarea), of the same tree.  Modify all files and test in the work area.  Then, make distclean in both trees.  Next, in the directory which contains both trees, do something like:

diff -urN dia-pristine dia-workarea >/tmp/some.patch
grep "^+++" /tmp/some.patch # check that no files have been unnecessarily
# touched, added or removed.
less /tmp/some.patch # check that patch is correct
gzip /tmp/some.patch

Send the patch as an attachment.  Don't send the same version of the patch twice on the list (when replying to yourself with updates...).  Keep large patches (> 5-40 kB) for private mails and/or in Bugzilla (URL in the mailing list is welcome, of course; small patches are okay, especially if some discussion on them is sought).

Much of the above is adapted from a mailing-list posting by Cyrille Chepelov.