* Robert Haas <robertmh...@gmail.com> [090527 21:30]: > > And actually looking at the history of the gpo repo, the branches are all > > messed up with "merges" and stuff that I'm not sure where they are coming > > from... 8.2, 8.3, and master(HEAD) are all the same as my gpo repo, but the > > back branchs are very bad... > > This is really quite horrible. What is the best way forward here?
That depends entirely on what the project wants. If you're just developing on HEAD with git to submit patches to official CVS use, don't do anything... HEAD is in good state in both repos. If you're using git to rebase patches and changes between branches, in order to submit patches for official CVS use, use the PostgreSQL.git I publish on repo.or.cz. It's back branches are in pretty good state too. If the "project" wants to provide canonical "git" repository as a cut-over from CVS, and CVS isn't going to be used anymore (other than served as an anonymous "mirror" of the git repo by git cvsserver, or have an old CVSROOT available as a public download for purely historical inspection), then it's probably best to do a single CVS->git conversion with one of the better tools (like parsecvs) that don't do incremental, and publish a set of good "graft" point for those using gpo who want to switch their current development onto the new git repo. But, since git's a completely Dvcs at its core, and was built by people thoroughly immersed in the tool-needs of vastly distributed VCS stuff, no matter what the project deems the "official" git repository, people will be able to continue to keep their current investment in git development with stuff like grafts, filter-branch, rebase, etc. a. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
signature.asc
Description: Digital signature
