<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div>Hi Graeme,</div><div><br class=""><blockquote type="cite" class=""><div class="WordSection1" style="page: WordSection1; font-family: LucidaSans; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 11pt;" class="">Can we revisit the idea of moving to git for cctbx?</span></div></div></blockquote><br class=""></div><div>This brings to mind a question I have been asking myself since the subject has been brought forth. The idea Paul wrote about on this list was a move to Github. I guess some, perhaps many, developers will keep interacting with the repository using subversion. I am worried this would clash with the workflow of those of us who would go the native git way. By that I mean creating many branches and merge points, which one would merge into the official repository when ready. I am worried the history would look very opaque for the subversion users. I would even probably create a fork on Github, making it even more opaque for a tool like subversion. Has anybody thought about such issues? My preferred solution would be for everybody to move to git but I don’t think that’s realistic. At the other end of the spectrum, there is putting in place a policy to keep the history linear.</div><div><br class=""></div><div>Best wishes,</div><div><br class=""></div><div>Luc</div><div><br class=""></div></body></html>