[vtk-developers] VTK moving to Git

[Mark Olesen]

On Thu, 2010-03-18 at 20:36 +0100, Jeff Baumes wrote:
> There are some somewhat large events coming up in the coming weeks
> for 
> VTK. The first is that we will be branching for a release (5.6) soon. 
> Also, about a week after the release is branched we will be moving 
> from a CVS repository to Git. There are several reasons for this, 
> including speed and stability. But the big win is collaboration and 
> workflow.

This is very good news (although life hasn't been so terrible anymore
after I discovered the KitWare mirrors on github).

One issue that could well be worth considering (in case it hasn't
already been considered) would be using submodules.
cf. http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html

They are admittedly somewhat more complicated to use than 'plain' git
usage, but for projects using VTK they would be a definite advantage.
I recently tried to pick out the vtkPolyhedron bits (from Will
Schroeder's and Hua Yang's repositories), but this proved to almost
impossible.
They have a VTK git repo, and I have a ParaView git repo, so any form of
merging is impossible, and without a common starting point, even
cherry-picking gets a bit hazardous.

If the VTK source were disentangled from ParaView, and linked in via a
git submodule, it would be much easier to transfer developments across.


BTW: have you given any thought to starting the git repository with a
completely clean branch and relegate all the previous changes to cvshead
(branch or repository)?

Following a recipe that I received from someone else (Bart Trojanowski):

- make a new branch for public releases

  $ git checkout -f -b master cvshead


- grab the SHA1 of the tree object under the most recent master commit

  $ git cat-file -p HEAD | grep '^tree'
  tree dfad7eb4fe4eb08c1aeea4e03c7fd27fbf3166eb


- now create a new commit, without any parents that points to the same
tree

  $ echo "public release v0.1" | \
    git commit-tree dfad7eb4fe4eb08c1aeea4e03c7fd27fbf3166eb

    6dec192924504eac766b54f17552008c1d1a326b


- finally set our public branch to point to this

  $ git update-ref refs/heads/public \
    6dec192924504eac766b54f17552008c1d1a326b


- then refresh
  $ git checkout -f



Finally, to mark the trees and branches as actually being related,
checkout the cvshead

  $ git checkout -f cvshead
  
and merge in the new sanitized branch

  $ git merge master


This would effectively 'restart' the history for the 'master' branch,
while preserving it for the 'cvshead' branch. To make cloning faster, it
might even be reasonable to have a separate repository with the old
changes.


/mark



DISCLAIMER:
This electronic transmission (and any attachments thereto) is intended solely for the use of the addressee(s). It may contain confidential or legally privileged information. If you are not the intended recipient of this message, you must delete it immediately and notify the sender. Any unauthorized use or disclosure of this message is strictly prohibited. Faurecia does not guarantee the integrity of this transmission and shall therefore never be liable if the message is altered or falsified nor for any virus, interception or damage to your system.