Re: Moving GLib and GTK+ to git
2009/4/6 Kristian Høgsberg k...@redhat.com: On Fri, 2009-04-03 at 02:28 +0200, Philipp wrote: /lurk 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 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
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. stdin:90: keyword msgctxt unknown stdin: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 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
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-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
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 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
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. stdin:90: keyword msgctxt unknown stdin: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. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
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 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
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 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. 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 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
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. stdin:90: keyword msgctxt unknown stdin: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 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Moving GLib and GTK+ to git
Le mardi 31 mars 2009 à 15:05 -0400, Matthias Clasen a écrit : 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've updated l10n.gnome.org for both modules: http://l10n.gnome.org/module/glib http://l10n.gnome.org/module/gtk+ Do you know if the hook that send a mail to gnomeweb at gnome dot org at each commit has been ported to git? 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. Regarding the ChangeLog policy, it's important for translators to have a unified method throughout the GNOME modules. As it seems the majority of modules won't keep a manual ChangeLog with git (like you're proposing with glib and gtk+), I suggest to all translators to follow the indication on the Walkthrough for translators compiled by Simos, that is to use only the commit message. http://live.gnome.org/GitMigration/Translators Cheers, Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
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-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
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 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
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 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Moving GLib and GTK+ to git
On Tue, Mar 31, 2009 at 3:58 PM, Behdad Esfahbod beh...@behdad.org 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 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
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 beh...@behdad.org 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 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
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 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
