From: Todd Z. <tm...@po...> - 2009-10-30 16:56:35
|
Greetings, We've completed the move from Subversion to Git for gtkpod and libgpod. Subversion is now read-only and will be removed from the default display at sourceforge.net after a few days or weeks. To browse the repositories via gitweb, visit: http://gtkpod.git.sourceforge.net/ To clone the libgpod repository anonymously, run: git clone git://gtkpod.git.sourceforge.net/gitroot/gtkpod/libgpod One of the goals in switching to git is to allow more collaboration. As Paul mentioned the other day, anyone can clone the repository and share it via git hosting sites like gitorious.org, repo.or.cz, github.com, and many others¹. This should lower the barrier to contribute and make it easier for those interested in particular improvements to work on them until they are nicely polished and then get them included in the official repository. It might be a good time to discuss some potential changes to the current workflow and practices. For instance, I'd love to see us stop using the ChangeLog file and instead rely on good, clean commit messages. When it comes time for a release, the commit logs can be used to create a NEWS or release notes file that summarizes the changes since the previous release. And we can either include a link to the commit logs in gitweb or generate a ChangeLog file during the 'make dist' process. Of course, what makes a "good, clean commit message" is subject to debate. I like the standards used by the git.git community, a short (~50 chars or so) subject line, followed by a blank line, then a more detailed description, if needed. Commits that can't be reasonably described in the subject most like should be split into several commits. Another subject would be branch policies, what branches should be in the official repositories, are any of them subject to rewinding/rebasing (ala git.git's next and pu branches). Anyway, I'm mostly just a git pedant and hopefully helpful integrator here, so I'll try to leave the finer points of working on the code to those of you who do the work. :) ¹ See http://git.or.cz/gitwiki/GitHosting for more -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It is not enough to be busy, so are the ants. The question is: what are we busy about? -- Henry David Thoreau |
From: Andrea <mar...@go...> - 2009-10-30 17:03:28
|
On 30/10/09 16:56, Todd Zullinger wrote: > Greetings, > > We've completed the move from Subversion to Git for gtkpod and > libgpod. Subversion is now read-only and will be removed from the > default display at sourceforge.net after a few days or weeks. > > To browse the repositories via gitweb, visit: > > http://gtkpod.git.sourceforge.net/ > > To clone the libgpod repository anonymously, run: > > git clone git://gtkpod.git.sourceforge.net/gitroot/gtkpod/libgpod Is it possible to get gtkpod and libgpod together? If I try git clone git://gtkpod.git.sourceforge.net/gitroot/gtkpod I get Initialized empty Git repository in /home/andrea/projects/cvs/3rdParty/ipod/gtkpod/.git/ fatal: The remote end hung up unexpectedly On the other end if I get them separately, it works. |
From: Todd Z. <tm...@po...> - 2009-10-30 17:09:28
|
Andrea wrote: > Is it possible to get gtkpod and libgpod together? The repositories are separate now (as they were back when we used CVS). The Subversion support on SourceForge did not allow this. > If I try > > git clone git://gtkpod.git.sourceforge.net/gitroot/gtkpod > > I get > > Initialized empty Git repository in /home/andrea/projects/cvs/3rdParty/ipod/gtkpod/.git/ > fatal: The remote end hung up unexpectedly > > On the other end if I get them separately, it works. So to clone gtkpod, you'd want: git clone git://gtkpod.git.sourceforge.net/gitroot/gtkpod/gtkpod Sorry for not making that all clear. :/ -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ He was busy creating hell for people who ask such questions. -- St. Augustin, in reply to "What was God doing before creation? |
From: Christophe F. <te...@gn...> - 2009-10-30 17:13:56
|
Hi Todd, 2009/10/30 Todd Zullinger <tm...@po...>: > We've completed the move from Subversion to Git for gtkpod and > libgpod. Subversion is now read-only and will be removed from the > default display at sourceforge.net after a few days or weeks. Thanks a lot for making this migration possible and handling all the little details to make things go as smoothly as possible. Now let's get back to work :) > It might be a good time to discuss some potential changes to the > current workflow and practices. For instance, I'd love to see us stop > using the ChangeLog file and instead rely on good, clean commit > messages. > Of course, what makes a "good, clean commit message" is subject to > debate. I like the standards used by the git.git community, a short > (~50 chars or so) subject line, followed by a blank line, then a more > detailed description, if needed. Commits that can't be reasonably > described in the subject most like should be split into several > commits. Yeah, I second all of that, though making a 50 characters description is hard. I remember reading some guidelines about what to put there, but I wasn't able to find it back :-/ > > Another subject would be branch policies, what branches should be in > the official repositories, are any of them subject to > rewinding/rebasing (ala git.git's next and pu branches). I'd just keep a master branch, and potentially a stable branch if need be, and I'd put all other work branches in personal repos. Christophe |
From: Todd Z. <tm...@po...> - 2009-10-30 17:34:32
|
Christophe Fergeau wrote: > Thanks a lot for making this migration possible and handling all the > little details to make things go as smoothly as possible. Now let's > get back to work :) Indeed, you've got some nice looking things happening with iPhone and iPod Touch support, with plenty of help from Héctor and the iFuse folks. > Yeah, I second all of that, though making a 50 characters > description is hard. Yeah, that's a general guideline but not a hard rule in git.git. > I remember reading some guidelines about what to put there, but I > wasn't able to find it back :-/ One place that I've seen often quoted is Tim Pope's blog: http://www.tpope.net/node/106 The git commit man page also mentions this: http://www.kernel.org/pub/software/scm/git/docs/git-commit.html#_discussion > I'd just keep a master branch, and potentially a stable branch if > need be, and I'd put all other work branches in personal repos. Sounds good. For now, we've got the plugin-framework branch which Paul has started. That will stay on to keep it visible and perhaps generate more interest. I suspect that after a while, more folks will begin to take advantage of collaborating via personal git repositories and we'll have less need for tracking that work in the official repositories. Ideally, the mailing list and IRC channel will make good places to gather, review patches, and coordinate. :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I always keep a supply of stimulant handy in case I see a snake - which I also keep handy. -- W. C. Fields |