Re: Moving GLib and GTK+ to git

[Matthias Clasen <matthias clasen gmail com>]

2009/3/31 Kristian Høgsberg <krh 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 <joe 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