Patches and feature requests

Note: feature requests should be added to the feature request tracker for discussion! When requesting features, please check the list archives to ensure that it hasn't been proposed before. You can also propose features on the mailing lists.

If you've changed the code in some way and you want your changes in the main distribution then you should post your changes to the mailing list.
If the project uses GIT (see Using GIT for instructions on getting hold of the latest version of a program) then you should commit your change(s) first to your local repository, like this:

After making your changes, do:

git commit -a

Enter a log message. The first line should be a short summary (like the subject of an email). Then leave a blank line, then write a longer description. This only commits to your local machine, so you don't need any special permission for this.

To view your patch after committing:

git show

If you realised you made a mistake, correct it and then do:

git commit -a --amend

Then, you have two options:

1. Push the changes to your public repository, then post to the mailing list telling us where your public repository is and which branch to pull from. If you don't have your own repository, you can click on 'fork' to create one (e.g. in the navigation bar at the top of http://repo.or.cz/w/rox-filer.git).
2. Create a patch which you can send to the mailing list directly like this:
   

     $ git format-patch origin/master
   

If the project uses subversion, do svn diff to create a patch and send it to the list.

Hints on getting patches accepted:

• Before implementing a new feature, it's a good idea to ask on the mailing list to see if people want it, or if there's a better way to do it.
• I have to read and check every patch carefully. Therefore, I get around to reading small patches much sooner than large ones!
• Each patch should only change one thing. The more things you change, the more likely I won't like one of them and it won't go in. It takes a lot of time to split patches up, so I tend to put it off.
• Don't add options. The code for making a new feature optional is easy to add later if some people really object to the new behaviour.

Translators: see Internationalisation for instructions on creating a language translation.