2009/3/31 Kristian Høgsberg <k...@redhat.com>: > > The glib and gtk+ repositories are up now and they are live: > > http://git.gnome.org/cgit/glib > http://git.gnome.org/cgit/gtk+ >
[...] > Other than that I'd say we're ready to go, but I'll leave it to Matthias to > make the call. Thanks so much, Kristian! So yes, I think we are ready to go. I am by no means a git master (that would be Kristian), so take what I am saying below with a grain of salt and correct me where necessary... Some things that we need to sort out include ChangeLog: The git way of doing things is to do small commits, with meaningful commit messages, and forego a separate ChangeLog file. Everybody who I talked to about this recommended going this way, so I'd say we should follow this. I'll add a final note to the current ChangeLog indicating this. I'll figure out what to do about autogenerating ChangeLogs in release tarballs in time for the next releases... Commit messages: Here are some recommendations that I think meet our needs: === 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 must not start with a capital letter. Don't use a trailing period either. Don't exceed 76 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 <j...@coder.org>" and --signoff. The one deviation in this from our current ChangeLog entry style is that it moves the bug reference from the short explanation to the main description. I'm not entirely sure which is better here, a little experimentation may be needed to come up with the best style. Working with branches: As Kristian explained to me, there are two basic approaches to handling bug fixes in git branches. Either commit the fix on the devel branch and cherry-pick it to the stable branch, or commit the fix to the stable branch and merge the whole stable branch to the devel branch periodically. While both approaches should work, the second one has the advantage of keeping more information about the availability of the fix in the git topology. Anyway, we don't have to create a 2.16 branch today, we can take a few days to feel our way into working with git before getting serious about major feature merges. I'll work on updating README.commits and similar files. Matthias _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list