Re: Upgrade of gettext on git.gnome.org (was Re: Moving GLib and GTK+ to git)
On Thu, 2009-04-02 at 16:56 -0400, Owen Taylor wrote: > On Thu, 2009-04-02 at 22:45 +0200, Olav Vitters wrote: > > On Thu, Apr 02, 2009 at 12:07:30PM +0200, Alexander Larsson wrote: > > > I've got a local branch with the rebased client-side-windows work. > > > However, I am unable to push it to git.gnome.org due to the pre-commit > > > hooks: > > > > > > The following translation (.po) file appears to be invalid. (When > > > updating branch 'client-side-windows'.) > > > po/af.po > > > The results of the validation follow. Please correct the errors on the > > > line numbers mentioned and try to push again. > > > :90: keyword "msgctxt" unknown > > > :90:8: parse error > > > . > > > > > > > > > Checking > > > http://git.gnome.org/cgit/gitadmin-bin/tree/pre-receive-check-po we > > > have: > > > > > > # gettext-0.14.6 on git.gnome.org isn't new enough to handle > > > # features such as msgctx > > > # dash_c="-c" > > > dash_c= > > > > So a gettext update should be done. CC'ed gnome-sysadmin. > > Upgrading the system gettext to a radically different version isn't > something that I want to do. My plan here is to create an RPM with just > the gettext utilities that installs in /usr/lib/gettext17 or something. > > (BTW, I temporarily disabled the hooks so Alex could push his branch.) I've now gone ahead and done this - there is a statically linked version of gettext-0.17 in /usr/libexec/gettext17 that the pre-receive check uses now. I've also reeneabled -c, so it should be doing a full set of checks. Let me know if any problems show up. - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
Edward Hervey schrieb: > On Tue, 2009-03-31 at 21:29 +0200, Martin Nordholts wrote: > >> Matthias Clasen wrote: >> >>> - 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. >>> >> Hi, >> >> Is there any particular reason for not starting with a capital letter, >> e.g. are there any tools that depend on it? In general I think a >> sentence look nicer if it starts with a capital letter, including those >> that does not end with a period. From a quick look at the most recent >> commit messages for the Linux kernel and git itself, it does not seem as >> if they have a rule such as the one above, which makes me even more >> curious why we should have it. >> > > FWIW, In GStreamer git repositories we use that same rule for the > one-liner with a subtle variation: > * We do allow capital letters (seriously, who cares? It looks nice) > * Considering you want to have as much info as possible in that > one-liner, we try to prefix it with a word giving a clue as to where the > work was done (without looking at the modified files). Doesn't apply if > it's a change accross the whole module. > Ex : >"rtspsrc: allow http:// on the proxy setting", or >"Mark unused arguments using G_GNUC_UNUSED glib macro." > > Edward > And we have a script to generate the ChangeLog for releases in gst too, right? Stefan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
2009/4/6 Kristian Høgsberg : > On Fri, 2009-04-03 at 02:28 +0200, Philipp wrote: >> >> >> Kristian Høgsberg wrote: >> > Just an update on my plan to possibly rebase the gtk+ repo: not going to >> > happen. What we have now is a good compromise between keeping all >> > history in the most correct form and how much work we want to put into >> > it. Again, no data is lost, we just have a few tags with some extra >> > files in them. >> How about deleting the broken tags from the git repos and keeping a >> little note somewhere buried deep in the docs/ dirs. Someone who cares >> about digging through history (like me) will then know to hit the >> historical CVS / SVN repositories for these specific missing tags. >> >> Its not like someone is going to re-roll tarballs from these tags ever >> again (or at least the chance is ~ ɛ). > > I don't see a good reason to delete the tags. They take virtually no > storage, and are mostly accurate except for the extra files. Last but > not least, they're a great help when browsing through history since most > repo viewers will annotate commits with the tag or branch if one or more > exists (for example, the GTK_2_16_0 tag on this page: > http://git.gnome.org/cgit/gtk+/log/?ofs=50) It would be better if you used more git compliant tags like "v2.16.0". Those tags make sense, but "BEFORE_FEDERICO_FILENAME_ENTRY_MERGE"... I don't think so. -- Felipe Contreras ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
On Fri, 2009-04-03 at 02:28 +0200, Philipp wrote: > > > Kristian Høgsberg wrote: > > Just an update on my plan to possibly rebase the gtk+ repo: not going to > > happen. What we have now is a good compromise between keeping all > > history in the most correct form and how much work we want to put into > > it. Again, no data is lost, we just have a few tags with some extra > > files in them. > How about deleting the broken tags from the git repos and keeping a > little note somewhere buried deep in the docs/ dirs. Someone who cares > about digging through history (like me) will then know to hit the > historical CVS / SVN repositories for these specific missing tags. > > Its not like someone is going to re-roll tarballs from these tags ever > again (or at least the chance is ~ ɛ). I don't see a good reason to delete the tags. They take virtually no storage, and are mostly accurate except for the extra files. Last but not least, they're a great help when browsing through history since most repo viewers will annotate commits with the tag or branch if one or more exists (for example, the GTK_2_16_0 tag on this page: http://git.gnome.org/cgit/gtk+/log/?ofs=50) cheers, Kristian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
On Fri, Apr 3, 2009 at 10:04 AM, Edward Hervey wrote: > On Tue, 2009-03-31 at 21:29 +0200, Martin Nordholts wrote: >> Matthias Clasen wrote: >> > - 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. >> >> Hi, >> >> Is there any particular reason for not starting with a capital letter, >> e.g. are there any tools that depend on it? In general I think a >> sentence look nicer if it starts with a capital letter, including those >> that does not end with a period. From a quick look at the most recent >> commit messages for the Linux kernel and git itself, it does not seem as >> if they have a rule such as the one above, which makes me even more >> curious why we should have it. > > FWIW, In GStreamer git repositories we use that same rule for the > one-liner with a subtle variation: > * We do allow capital letters (seriously, who cares? It looks nice) > * Considering you want to have as much info as possible in that > one-liner, we try to prefix it with a word giving a clue as to where the > work was done (without looking at the modified files). Doesn't apply if > it's a change accross the whole module. > Ex : > "rtspsrc: allow http:// on the proxy setting", or > "Mark unused arguments using G_GNUC_UNUSED glib macro." This is also the guideline used in git.git, and it looks pretty good: id: fix foobar or if there's no id: Generic cleanup Note that no full-stop is used. -- Felipe Contreras ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
On Tue, 2009-03-31 at 21:29 +0200, Martin Nordholts wrote: > Matthias Clasen wrote: > > - 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. > > Hi, > > Is there any particular reason for not starting with a capital letter, > e.g. are there any tools that depend on it? In general I think a > sentence look nicer if it starts with a capital letter, including those > that does not end with a period. From a quick look at the most recent > commit messages for the Linux kernel and git itself, it does not seem as > if they have a rule such as the one above, which makes me even more > curious why we should have it. FWIW, In GStreamer git repositories we use that same rule for the one-liner with a subtle variation: * We do allow capital letters (seriously, who cares? It looks nice) * Considering you want to have as much info as possible in that one-liner, we try to prefix it with a word giving a clue as to where the work was done (without looking at the modified files). Doesn't apply if it's a change accross the whole module. Ex : "rtspsrc: allow http:// on the proxy setting", or "Mark unused arguments using G_GNUC_UNUSED glib macro." Edward > > BR, > Martin > ___ > gnome-i18n mailing list > gnome-i...@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
Kristian Høgsberg wrote: > Just an update on my plan to possibly rebase the gtk+ repo: not going to > happen. What we have now is a good compromise between keeping all > history in the most correct form and how much work we want to put into > it. Again, no data is lost, we just have a few tags with some extra > files in them. How about deleting the broken tags from the git repos and keeping a little note somewhere buried deep in the docs/ dirs. Someone who cares about digging through history (like me) will then know to hit the historical CVS / SVN repositories for these specific missing tags. Its not like someone is going to re-roll tarballs from these tags ever again (or at least the chance is ~ ɛ). Ciao, Philipp ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
On 04/03/2009 03:04 AM, Edward Hervey wrote: FWIW, In GStreamer git repositories we use that same rule for the one-liner with a subtle variation: * We do allow capital letters (seriously, who cares? It looks nice) * Considering you want to have as much info as possible in that one-liner, we try to prefix it with a word giving a clue as to where the work was done (without looking at the modified files). Doesn't apply if it's a change accross the whole module. Ex : "rtspsrc: allow http:// on the proxy setting", or "Mark unused arguments using G_GNUC_UNUSED glib macro." Right. In cairo and pango we do the same, with a slightly different syntax. For example: [win32] Fix horizontal glyph positioning bug [test] Memfault checks [surface] Propagate region allocation failure [traps] Propagate allocation failure [region] Use const cairo_rectangle_int_t consistently [scaled-font] Global glyph cache I find that quite useful. behdad Edward BR, Martin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
Owen Taylor wrote: > On Fri, 2009-04-03 at 06:23 +, Stef Walter wrote: > >> Kristian Høgsberg wrote: >> >>> So unless we find a show-stopper bug in the import >>> within the next few days, what's on git.gnome.org now is final. >>> >> Not a show stopper, but it'd be cool to migrate the svn-ignore property >> over into .gitignore files. Or is this to be handled some other way? >> > > The svn-ignore property and .gitignore files are different in various > ways; an automated conversion would be challenging. So the current > plan is just that people need to create new .gitignore files. > > - Owen > In my experience (for babl and GEGL), a simple git svn create-ignore does a good job. - Martin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
On Fri, 2009-04-03 at 06:23 +, Stef Walter wrote: > Kristian Høgsberg wrote: > > So unless we find a show-stopper bug in the import > > within the next few days, what's on git.gnome.org now is final. > > Not a show stopper, but it'd be cool to migrate the svn-ignore property > over into .gitignore files. Or is this to be handled some other way? The svn-ignore property and .gitignore files are different in various ways; an automated conversion would be challenging. So the current plan is just that people need to create new .gitignore files. - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
Kristian Høgsberg wrote: > So unless we find a show-stopper bug in the import > within the next few days, what's on git.gnome.org now is final. Not a show stopper, but it'd be cool to migrate the svn-ignore property over into .gitignore files. Or is this to be handled some other way? Cheers, Stef ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Upgrade of gettext on git.gnome.org (was Re: Moving GLib and GTK+ to git)
On Thu, 2009-04-02 at 22:45 +0200, Olav Vitters wrote: > On Thu, Apr 02, 2009 at 12:07:30PM +0200, Alexander Larsson wrote: > > I've got a local branch with the rebased client-side-windows work. > > However, I am unable to push it to git.gnome.org due to the pre-commit > > hooks: > > > > The following translation (.po) file appears to be invalid. (When > > updating branch 'client-side-windows'.) > > po/af.po > > The results of the validation follow. Please correct the errors on the > > line numbers mentioned and try to push again. > > :90: keyword "msgctxt" unknown > > :90:8: parse error > > . > > > > > > Checking > > http://git.gnome.org/cgit/gitadmin-bin/tree/pre-receive-check-po we > > have: > > > > # gettext-0.14.6 on git.gnome.org isn't new enough to handle > > # features such as msgctx > > # dash_c="-c" > > dash_c= > > So a gettext update should be done. CC'ed gnome-sysadmin. Upgrading the system gettext to a radically different version isn't something that I want to do. My plan here is to create an RPM with just the gettext utilities that installs in /usr/lib/gettext17 or something. (BTW, I temporarily disabled the hooks so Alex could push his branch.) - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Upgrade of gettext on git.gnome.org (was Re: Moving GLib and GTK+ to git)
On Thu, Apr 02, 2009 at 12:07:30PM +0200, Alexander Larsson wrote: > I've got a local branch with the rebased client-side-windows work. > However, I am unable to push it to git.gnome.org due to the pre-commit > hooks: > > The following translation (.po) file appears to be invalid. (When > updating branch 'client-side-windows'.) > po/af.po > The results of the validation follow. Please correct the errors on the > line numbers mentioned and try to push again. > :90: keyword "msgctxt" unknown > :90:8: parse error > . > > > Checking > http://git.gnome.org/cgit/gitadmin-bin/tree/pre-receive-check-po we > have: > > # gettext-0.14.6 on git.gnome.org isn't new enough to handle > # features such as msgctx > # dash_c="-c" > dash_c= So a gettext update should be done. CC'ed gnome-sysadmin. -- Regards, Olav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
On Mon, 2009-03-30 at 12:47 -0400, Matthias Clasen wrote: > Last week, I said that I'd like to get this done by the end of March, > which is almost upon us now. I've got a local branch with the rebased client-side-windows work. However, I am unable to push it to git.gnome.org due to the pre-commit hooks: The following translation (.po) file appears to be invalid. (When updating branch 'client-side-windows'.) po/af.po The results of the validation follow. Please correct the errors on the line numbers mentioned and try to push again. :90: keyword "msgctxt" unknown :90:8: parse error . Checking http://git.gnome.org/cgit/gitadmin-bin/tree/pre-receive-check-po we have: # gettext-0.14.6 on git.gnome.org isn't new enough to handle # features such as msgctx # dash_c="-c" dash_c= This means whats currently in gtk+ master branch does not pass the commit checks, so we can't branch master even if no changes are made to the pofiles. Also, it means we can't do updates to the pofiles in master that uses msgctxt. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
On Wed, 2009-04-01 at 08:43 +0200, Mike Massonnet wrote: > Except the 72 characters, cause you will really want a better terminal > instead. It's mostly a recommendation to enforce a short summary, but > even 100 characters should be fine. It's not so much about the terminal; it's about the fact that plain-text emails are wrapped at 70-something and we want the summaries (git log| git shortlog) to appear without wrapping. David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
On Tue, 2009-03-31 at 15:05 -0400, Matthias Clasen wrote: > 2009/3/31 Kristian Høgsberg : > > > > > 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. Just an update on my plan to possibly rebase the gtk+ repo: not going to happen. What we have now is a good compromise between keeping all history in the most correct form and how much work we want to put into it. Again, no data is lost, we just have a few tags with some extra files in them. So unless we find a show-stopper bug in the import within the next few days, what's on git.gnome.org now is final. cheers, Kristian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
Am Wed, 1 Apr 2009 08:43:45 +0200 schrieb Mike Massonnet : > Le Tue, 31 Mar 2009 18:06:56 -0400, > David Zeuthen a écrit : > > > On Tue, 2009-03-31 at 17:03 -0400, Matthias Clasen wrote: > > > On Tue, Mar 31, 2009 at 3:58 PM, Behdad Esfahbod > > > wrote: > > > > On 03/31/2009 03:50 PM, David Zeuthen wrote: > > > >> > > > >> Personally I prefer non-capital and no periods; it makes the > > > >> output of 'git log |git shortlog' nicer to look at (see [1] for > > > >> an example) but maybe that's just me. I think capital letters > > > >> would work nice here too; trailing periods would probably look > > > >> weird though. > > > > > > > > While I prefer to capitalize sentence starters, NOT capitalizing > > > > makes it easier to start a commit summary with an API symbol > > > > name or other identifiers that should not be capitalized. > > > > > > I don't have any strong preferences. How about the following > > > amended version: > > > > > > 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. > > > > Sounds good to me. And it would be really nice to enforce this > > using a git hook (repeating myself, I know). > > Except the 72 characters, cause you will really want a better terminal > instead. It's mostly a recommendation to enforce a short summary, but > even 100 characters should be fine. For what I want, it also makes summaries nicer and enables you to keep editor or repository viewer windows small. Even though it's the traditional origin I don't think old terminals are the sole reason. Just my 2 pfennig, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
Le Tue, 31 Mar 2009 18:06:56 -0400, David Zeuthen a écrit : > On Tue, 2009-03-31 at 17:03 -0400, Matthias Clasen wrote: > > On Tue, Mar 31, 2009 at 3:58 PM, Behdad Esfahbod > > wrote: > > > On 03/31/2009 03:50 PM, David Zeuthen wrote: > > >> > > >> Personally I prefer non-capital and no periods; it makes the > > >> output of 'git log |git shortlog' nicer to look at (see [1] for > > >> an example) but maybe that's just me. I think capital letters > > >> would work nice here too; trailing periods would probably look > > >> weird though. > > > > > > While I prefer to capitalize sentence starters, NOT capitalizing > > > makes it easier to start a commit summary with an API symbol name > > > or other identifiers that should not be capitalized. > > > > I don't have any strong preferences. How about the following > > amended version: > > > > 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. > > Sounds good to me. And it would be really nice to enforce this using a > git hook (repeating myself, I know). Except the 72 characters, cause you will really want a better terminal instead. It's mostly a recommendation to enforce a short summary, but even 100 characters should be fine. My 2 cents Mike ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
On Tue, 2009-03-31 at 17:03 -0400, Matthias Clasen wrote: > On Tue, Mar 31, 2009 at 3:58 PM, Behdad Esfahbod wrote: > > On 03/31/2009 03:50 PM, David Zeuthen wrote: > >> > >> Personally I prefer non-capital and no periods; it makes the output of > >> 'git log |git shortlog' nicer to look at (see [1] for an example) but > >> maybe that's just me. I think capital letters would work nice here too; > >> trailing periods would probably look weird though. > > > > While I prefer to capitalize sentence starters, NOT capitalizing makes it > > easier to start a commit summary with an API symbol name or other > > identifiers that should not be capitalized. > > I don't have any strong preferences. How about the following amended version: > > 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. Sounds good to me. And it would be really nice to enforce this using a git hook (repeating myself, I know). David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
On Tue, Mar 31, 2009 at 3:58 PM, Behdad Esfahbod wrote: > On 03/31/2009 03:50 PM, David Zeuthen wrote: >> >> Personally I prefer non-capital and no periods; it makes the output of >> 'git log |git shortlog' nicer to look at (see [1] for an example) but >> maybe that's just me. I think capital letters would work nice here too; >> trailing periods would probably look weird though. > > While I prefer to capitalize sentence starters, NOT capitalizing makes it > easier to start a commit summary with an API symbol name or other > identifiers that should not be capitalized. I don't have any strong preferences. How about the following amended version: 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. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
On Tue, 2009-03-31 at 15:58 -0400, Behdad Esfahbod wrote: > On 03/31/2009 03:50 PM, David Zeuthen wrote: > > Personally I prefer non-capital and no periods; it makes the output of > > 'git log |git shortlog' nicer to look at (see [1] for an example) but > > maybe that's just me. I think capital letters would work nice here too; > > trailing periods would probably look weird though. > > While I prefer to capitalize sentence starters, NOT capitalizing makes it > easier to start a commit summary with an API symbol name or other identifiers > that should not be capitalized. OTOH for the other style sometimes you want to start the summary with an abbreviation, e.g. "HIG fixes". FWIW, my view is that we should capitalize summaries as most of the summaries from the importer already starts with a capital letter. David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
On Tue, 2009-03-31 at 15:05 -0400, Matthias Clasen wrote: > Commit messages: Here are some recommendations that I think meet our needs: It would be nice to have hooks to enforce this in the master repo at git.gnome.org. Thoughts? > 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. Do we want to recommend that contributors 1. submit patches to bugzilla (like we've done up until now) 2. publish a git repo with their changes Surely we would need to handle both, but it's my experience that it is much easier for maintainers to work with 2. Especially for more complicated features that include a series of patches. So maybe we want to actually recommend workflow 2 to contributors. Maybe even add some bugzilla-bling-integration, I don't know. David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
On 03/31/2009 03:50 PM, David Zeuthen wrote: Personally I prefer non-capital and no periods; it makes the output of 'git log |git shortlog' nicer to look at (see [1] for an example) but maybe that's just me. I think capital letters would work nice here too; trailing periods would probably look weird though. While I prefer to capitalize sentence starters, NOT capitalizing makes it easier to start a commit summary with an API symbol name or other identifiers that should not be capitalized. behdad David [1] : David Zeuthen (198): [...] add some notes about terminology use the term "Name" instead of "Label" when creating a partition rework terminology for filesystem labels / partition labels fix compiler warnings introduced by the last set of patches add some experimental code for grid-based layout fix some criticals where we tried to access non-existant widgets rework partition table handling Matthias Clasen (13): HIG fixes trivial coding style fix avoid dialog resizing don't allow empty passphrases improved spacing for sections [...] ___ gnome-i18n mailing list gnome-i...@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
Hi, On Tue, 2009-03-31 at 21:29 +0200, Martin Nordholts wrote: > Matthias Clasen wrote: > > - 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. (Btw, should probably say 72 characters so 'git log | git shortlog' output is bounded to 80 characters so it's bearable to look at in a normal terminal; see below for details.) > > Hi, > > Is there any particular reason for not starting with a capital letter, > e.g. are there any tools that depend on it? In general I think a > sentence look nicer if it starts with a capital letter, including those > that does not end with a period. From a quick look at the most recent > commit messages for the Linux kernel and git itself, it does not seem as > if they have a rule such as the one above, which makes me even more > curious why we should have it. I think it's just about consistency (having some commits start with a non-capital and some start with a capital looks weird; ditto for trailing periods) not so much about about a preference on whether it should be non-capital/capital. Personally I prefer non-capital and no periods; it makes the output of 'git log |git shortlog' nicer to look at (see [1] for an example) but maybe that's just me. I think capital letters would work nice here too; trailing periods would probably look weird though. David [1] : David Zeuthen (198): [...] add some notes about terminology use the term "Name" instead of "Label" when creating a partition rework terminology for filesystem labels / partition labels fix compiler warnings introduced by the last set of patches add some experimental code for grid-based layout fix some criticals where we tried to access non-existant widgets rework partition table handling Matthias Clasen (13): HIG fixes trivial coding style fix avoid dialog resizing don't allow empty passphrases improved spacing for sections [...] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
On 03/31/2009 03:05 PM, Matthias Clasen wrote: 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... Feel free to copy from Pango. Pango only has one ChangeLog though. You may want to consolidate gtk's many ones now. 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. For Pango I continue to use the bug title line as my short summary. If needed, I retitle the bug first. For example: commit cf13cde8a80c9a1a9d4c9e343c634350da59991a Author: Behdad Esfahbod Date: Thu Mar 26 01:03:43 2009 -0400 Bug 571291 – Unicode 5.1 support in pango - Indic Lanuages Add char class for new characters. Patch from Rahul Bhalerao. commit 477747bc1ef1078b06c4e1c615a1a912e6ada299 Author: Sebastian Dröge Date: Mon Mar 23 19:16:58 2009 -0400 Bug 576298 – Fails to link pango-view if --without-x is specified but cairo has X11 support commit c82e8ad9dda142b1acfbcb86054750e082600893 Author: Behdad Esfahbod Date: Mon Mar 16 17:25:33 2009 -0400 Bug 547963 – man page for pango-view commit 69e1f7921525c2849d937b5a822475007a4f9a2f Author: Behdad Esfahbod Date: Mon Mar 16 16:57:58 2009 -0400 Bug 502804 – pango-view or pangocairo-view option to annotate Added --annotate. Also fixes: Bug 502801 – per-backend pango-view options behdad ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
Matthias Clasen wrote: > - 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. Hi, Is there any particular reason for not starting with a capital letter, e.g. are there any tools that depend on it? In general I think a sentence look nicer if it starts with a capital letter, including those that does not end with a period. From a quick look at the most recent commit messages for the Linux kernel and git itself, it does not seem as if they have a rule such as the one above, which makes me even more curious why we should have it. BR, Martin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
I should have also mentioned that the commands you need are: git clone git://git.gnome.org/glib git clone git://git.gnome.org/gtk+ A lot more information about the git migration and git in general can be found at http://live.gnome.org/GitMigration. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving GLib and GTK+ to git
2009/3/31 Kristian Høgsberg : > > 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 " 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
Re: Moving GLib and GTK+ to git
On Mon, 2009-03-30 at 12:47 -0400, Matthias Clasen wrote: > Last week, I said that I'd like to get this done by the end of March, > which is almost upon us now. > > Therefore, I'd like to ask everybody to hold off with committing to > svn. While we are not quite ready to start the migration yet, it will > begin sometime later today. So to avoid duplicate work, it would be > best to wait with further commits to glib and gtk+ until the migration > is completed. I'll send another email with checkout information, etc, > when the conversion is done. The glib and gtk+ repositories are up now and they are live: http://git.gnome.org/cgit/glib http://git.gnome.org/cgit/gtk+ and I've been verifying that master and all tags are identical between git and svn. There are some differences for some of the older cvs tags, but it looks like they break down into two cases: 1) CVS tagging races with a commit: person A does cvs up, cvs commit, make dist, person B does cvs commit, A does cvs commit, and gets no conflicts with person B's commit, then does cvs tag. The tag now references files from before the B commit and file from after the B commit. This is possible with CVS and SVN can represent it by breaking the svn cp for the tag into a piece-wise copy from different revisions. With git, a tag just points to a existing commit, so to do this, we'd have to create a commit that matches what the cvs tag contains. Check out 1.3.12 for an example. It's only a problem for a few old cvs era commits and the effect is that the git tag will contain a commit that wasn't in the tarball or cvs tag. It won't affect other parts of history, specifically, git blame information is still accurate. I've talked with Owen and Matthias about it and we don't feel it's an issue that's worth tackling. 2) CVS repos that were copied into the gtk+ repo on the server. Three main cases are gdk-pixbuf, the reference docs and the pixbuf theme engine. These were all either started as their own cvs repo or part of another repo. The RCS (the ,v files) were copied on the server to pull them into gtk+ with full history. CVS implements tagging by tagging every RCS file, so every RCS contains all the tags from the repo, and when you move an RCS file, the tags move with it. Git doesn't support tagging just a sub-directory so what the CVS to git importer does in this case is to expand the tag to cover the entire tree. This means that a gdk-pixbuf tag from when it was an independent repo will now include gtk+ files in it and vice versa. The consequence is that checking out an old gtk+ tag from before gdk-pixbuf (or the docs or the pixbuf theme engine) got merged may have the gdk-pixbuf files in it. Again, this only affects older CVS tags, doesn't throw away information and most important, doesn't affect git blame output. Ideally we could split out the gdk-pixbuf history from before the RCS files got copied into a branch with a different initial commit and create a merge commit where the two histories join. I'm going to take a couple of hours to look at this, but I suspect it may not doable with reasonable effort. I mean, this theory is nice and all, but when it comes down to the nitty-gritty shell-quoting details of making it actually work I may end up concluding that it's just not practical. So, with the caveat that we might rebase the gtk+ repo, glib and gtk+ are now in git! If we end up getting a fix for 2), we'll rebase and replay whatever commits happened in the meantime to the rebased tree. If you don't know what to do if an upstream repo rebases, it's probably best to hold off committing to the git repos a little longer. Other than that I'd say we're ready to go, but I'll leave it to Matthias to make the call. cheers, Kristian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Moving GLib and GTK+ to git
Last week, I said that I'd like to get this done by the end of March, which is almost upon us now. Therefore, I'd like to ask everybody to hold off with committing to svn. While we are not quite ready to start the migration yet, it will begin sometime later today. So to avoid duplicate work, it would be best to wait with further commits to glib and gtk+ until the migration is completed. I'll send another email with checkout information, etc, when the conversion is done. See you all on the other side ! Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
