0
$\begingroup$

Rosanswers logo

I am setting up a repository which will contain several ROS stacks. I want rosinstall and ros_release to manage each stack separately. I know how to do it with svn, but git seems to force the whole repository to be managed as a unit.

  • Is there a way to use git that meets these requirements?

  • Do I need a separate git repository for each stack?


Originally posted by joq on ROS Answers with karma: 25443 on 2011-06-19

Post score: 3

$\endgroup$

2 Answers 2

0
$\begingroup$

Rosanswers logo

You need to map git repositories directly onto stacks as you cannot do partial checkouts of git repositories. For source-based installs using rosinstall, you can get into bad states if you are using more than one stack from a single git repository. Another way to think of it is, outside of ROS, if you were releasing a software library, you would have a separate repository for that software library, i.e. we generally map releasable units to separate repositories.

You can, however, use git submodules to create larger, virtual repositories. git submodules are not seamless, but they are the closest to combining the aggregate 'give me everything' behavior of SVN and managing release-able units separately.


Originally posted by kwc with karma: 12244 on 2011-06-19

This answer was ACCEPTED on the original site

Post score: 4

$\endgroup$
0
$\begingroup$

Rosanswers logo

Just for future reference: The preferred way now seems to be releasing every stack as a separate git repository, then adding them to a rosinstall file and adding that to the indexer. See this mail by Ken Conley to ros-users. This approach makes it possible to develop and check out each stack separately while avoiding problems with Git submodules (such as this one).


Originally posted by Martin Günther with karma: 11816 on 2012-02-03

This answer was NOT ACCEPTED on the original site

Post score: 4

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.