[gmx-developers] Major code reorganization in git coming up

[Mark Abraham]

On 12/31/10, Erik Lindahl  <erik at kth.se> wrote:
> Hi!
> 
> We figured we'd celebrate the upcoming new year with some major changes in the git development branch, consisting primarily of C++ support and a more modular organization of files.
> This is a gradual process, so this mail is a bit of a warning-message that the master/development branch might have some issues with compilers/build environments the next couple of weeks.
> 

Wouldn't creating an "unstable" branch be a better approach to a known lengthy period of instability? Now people working off (or fixing) the master branch don't have to change their workflows at all. If bugfix commits or merges from release-4-5-patches happen into master, that's great, and don't affect unstable at all. git branches are lightweight and seem correct to use on almost any excuse.

Later, once "unstable" has matured a bit, 

git rebase master
git checkout master
git merge unstable

will create the impression that development on master was seamless. No ugly "merge commits", and the "unstable" branch just quietly goes away afterwards.


> If you occasionally use a git build to run production simulation, just use the release-4-5-patches branch instead, and everything should be fine.
> 
> However, If you are working on your own code based on the git master branch, it might be a good idea to either switch to the release-4-5-patches branch, or create your own branch that you no longer sync with master as frequently. In the latter case you might have to go through some pain to port your code back to the new file organization later (sorry about that).
> 

git provides a good technique for switching away from master, provided you've been a good coder and made your own local branch:

git rebase --onto origin/release-4-5-patches origin/master your-local-branch

If you haven't made your own local branch (which, after all, is just an alias to a commit) then you can probably substitute suitable git commit hashes into the above. Or do an interactive rebase to create the impression that you've done a continuous series of local commits from the current origin/master HEAD, then name your branch, and then rebase --onto.

Mark


> The upside of all this is that the file organization will gradually get easier to understand, and the code itself should also get much more modular and readable (which we hope will lead to a faster release schedule and more features :-)
> 
> 
> 
> Happy new year!
> 
> 
> Erik
> 
> 
> 
> --
> Erik Lindahl <erik at kth.se>
> Professor of Theoretical & Computational Biophysics
> Department of Theoretical Physics & Swedish e-Science Research Center
> Royal Institute of Technology, Stockholm, Sweden
> Tel: +46855378029 Cell: +46703844534 
> 
> -- 
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the 
> www interface or send it to gmx-developers-request at gromacs.org.
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20110105/a6d56480/attachment.html>