[vtk-developers] VTK moving to Git

[Berk Geveci]

In all likelihood, VTK will be a submodule. At least, later in the Git history.

This Git repo will be completely incompatible with the existing Git
repository so there will be no cvshead branch in it. Brad King is
putting a lot of effort into cleaning VTK and ParaView histories. It
will be very cool but totally incompatible with existing Git repos.

-berk

On Fri, Mar 19, 2010 at 10:02 AM, Mark Olesen <Mark.Olesen at faurecia.com> wrote:
> 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.
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>