On Thu, May 28, 2009 at 11:04 AM, Greg Stark <st...@enterprisedb.com> wrote: > On Thu, May 28, 2009 at 3:52 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Andrew Dunstan <and...@dunslane.net> writes: >>> Robert Haas wrote: >>>> That would suck for me. I use git log a lot to see how things have >>>> changed over time. >> >>> Indeed. Losing the history is not an acceptable option. >> >> I think the same. If git is not able to maintain our project history >> then it is not mature enough to be considered as our official VCS. >> This is not a negotiable requirement. > > I think the idea is that you could choose, for example, the level of > granularity you want to keep. That could be interesting in the future > -- someone who submitted a patch (or anyone who was working in that > area) might want to keep all their intermediate commits and not just > the one big commit for the whole feature.
I don't think that was the idea - Aidan floated the idea of just checking the current version of each branch into git, rather than importing the full history from CVS (and letting indivdual cloners fix their own history if they were so inclined). I think that's a non-starter. I'm still not sure who is going to take responsibility for fixing the git tree we have now. I don't think it's going to work for us to leave it broken until we're ready to do "the cutover", and then do one monolithic move. If the tools we're using to do the import now have broken our tree, then we need to fix it, and them. Ideally I'd like to get a bi-directional conversion working, so that committers could commit via either CVS or GIT during the transition, but I'm not sure whether that's feasible. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers