[nautilus] Add README.commits, update HACKING for git

[Alexander Larsson <alexl src gnome org>]

commit a867c35e835128647396ad5b2df498c189944ca4
Author: Alexander Larsson <alexl redhat com>
Date:   Fri Apr 17 13:44:19 2009 +0200

    Add README.commits, update HACKING for git
---
 HACKING        |   13 ++++++----
 Makefile.am    |    1 +
 README.commits |   68 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 77 insertions(+), 5 deletions(-)

diff --git a/HACKING b/HACKING
index 0b1e132..ee72e52 100644
--- a/HACKING
+++ b/HACKING
@@ -6,9 +6,10 @@ in releases on the GNOME FTP site
 (http://ftp.gnome.org/pub/GNOME/sources/nautilus/).
 
 If you plan to hack on Nautilus, please make sure you work from the
-SVN version. The SVN version can be checked from the GNOME svn server.
-See http://developer.gnome.org/tools/svn.html for details on how to get 
-started with GNOME SVN.
+Git version. The Git version can be checked from the GNOME git server.
+See http://live.gnome.org/GitMigration for details on how to get 
+started with GNOME Git. For details on how Nautilus uses git, see
+the README.commits file.
 
 If you want to contribute in development discussions, please send mail
 to the nautilus mailing list: <nautilus-list gnome org>.  Archives and
@@ -23,7 +24,7 @@ If you've been working on a change to Nautilus and want to propose it
 for inclusion, you have to generate a patch and submit it for review
 by the maintainers.
 
-Patches should be made with 'svn diff --diff-cmd diff -x -up >patch'
+Patches should be made with 'git format-patch -M'
 and should conform to Nautilus coding style as described in
 docs/style-guide.html. We are pretty strict about coding style, so
 please make sure you follow the style guide to avoid unnecessary
@@ -36,7 +37,9 @@ bugzilla (http://bugzilla.gnome.org, product 'nautilus'). If you do
 this, please send a mail to the list saying you did so, because it is
 very easy for the bugzilla email to get lost in all the bugzilla
 reports, and only the people CCd on the bug can partake in the
-discussion.
+discussion. When attaching bugs to bugzilla from git the git-bz
+command can be helpful, see:
+http://blog.fishsoup.net/2008/11/16/git-bz-bugzilla-subcommand-for-git/
 
 The Nautilus maintainers do their best to review patches and help
 developers that want to work on something, however we are often
diff --git a/Makefile.am b/Makefile.am
index dde13e2..8d2b5bf 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -31,6 +31,7 @@ EXTRA_DIST=					\
 	COPYING-DOCS				\
 	HACKING					\
 	MAINTAINERS				\
+	README.commits				\
 	nautilus.desktop			\
 	nautilus.desktop.in			\
 	ChangeLog-20000414			\
diff --git a/README.commits b/README.commits
new file mode 100644
index 0000000..63c4056
--- /dev/null
+++ b/README.commits
@@ -0,0 +1,68 @@
+Nautilus is part of the GNOME git repository. At the current time, any
+person with write access to the GNOME repository, can make changes to
+Nautilus. This is a good thing, in that it encourages many people to work
+on Nautilus, and progress can be made quickly. However, we'd like to ask
+people committing to Nautilus to follow a few rules:
+
+0) Ask first. If your changes are major, or could possibly break existing
+   code, you should always ask. If your change is minor and you've
+   been working on GVfs for a while it probably isn't necessary
+   to ask. But when in doubt, ask. Even if your change is correct,
+   somebody may know a better way to do things.
+
+   If you are making changes to Nautilus, you should be subscribed
+   to nautilus-list gnome org  (Subscription address:
+   nautilus-list-request gnome org ) This is a good place to ask
+   about intended changes.
+
+   #nautilus on GIMPNet (irc.gimp.org, irc.us.gimp.org, irc.eu.gimp.org, ...)
+   is also a good place to find Nautilus developers to discuss changes with.
+
+1) Ask _first_.
+
+2) With git, we no longer maintain a ChangeLog file, but you are expected
+   to produce a meaningful commit message. Changes without a sufficient
+   commit message will be reverted. See below for the expected format
+   of commit messages.
+
+3) Try to separate each change into multiple small commits that are
+   independent ("micro commits" in git speak). This way its easier to
+   see what each change does, making it easier to review, to cherry pick
+   to other branches, to revert, and to bisect.
+
+Notes:
+
+* When developing larger features or complicated bug fixes, it is
+  advisable to work in a branch in your own cloned Nautilus repository.
+  You may even consider making your repository publically available
+  so that others can easily test and review your changes.
+
+* The expected format for git commit messages is as follows:
+
+=== begin example commit ===
+Short explanation of the commit
+
+Longer explanation explaining exactly what's changed, whether any
+external or private interfaces changed, what bugs were fixed (with bug
+tracker reference if applicable) and so forth. Be concise but not too brief.
+=== end example commit ===
+
+  - Always add a brief description of the commit to the _first_ line of
+    the commit and terminate by two newlines (it will work without the
+    second newline, but that is not nice for the interfaces).
+
+  - First line (the brief description) must only be one sentence and
+    should start with a capital letter unless it starts with a lowercase
+    symbol or identifier. Don't use a trailing period either. Don't exceed
+    72 characters.
+
+  - The main description (the body) is normal prose and should use normal
+    punctuation and capital letters where appropriate. Normally, for patches
+    sent to a mailing list it's copied from there.
+
+  - When committing code on behalf of others use the --author option, e.g.
+    git commit -a --author "Joe Coder <joe coder org>" and --signoff.
+
+
+Alexander Larsson
+17 Apr 2009