0

I like to reuse some code of a GIT maintained project for another project. The working code is a good kickstart to the new project, despite most of it would come obsolete for the new needs. So the question is what would be the best practice for handling that?

I could

  • Make a new repository for the new thing and cherry pick the files from the old project. After stripping the code to match the needed basic funcitonality of the new project do the first commit to keep it's history clean from useless things. Maybe it takes some time to conform this goal. Also, there is no way to merge enhancements done in the old project.

  • Branch the old code and adapt it to it's new job step by step. That means the two projects will stay entangled inside one repository, that has one name, one README on GitHub etc.

  • Create the new project, beginning with a minimal main part, and another library project, serving as a common collection for both the old and the new project. However, with HTML and JS development, that makes many headaches as importing is complex in JS, impossible in HTML, there is the need to pull two repo's to get each of the project running etc.

What would you do? Are there any GIT tricks that would support me?

Bharat Sinha
  • 13,973
  • 6
  • 39
  • 63
dronus
  • 10,774
  • 8
  • 54
  • 80

3 Answers3

0

What I would have done (my terms might relate to svn)...

A. Create a new repository and put the existing code as a branch

B. Start initial development on that branch itself...

C. Once you reach a stage where you feel that the branch can serve as base for the new project move it in trunk...

It's an off-beat way but will allow you to keep trunk as clean as possible. Since it's migrated code so the complete cleaning process will take a number of releases... but the attempt should be start with as clean as possible with minimum effort.

Bharat Sinha
  • 13,973
  • 6
  • 39
  • 63
0

What I would do (I DO use Git). Is as follows:

  1. Check out the old project.
  2. Create an entirely new repository for my new project.
  3. Keep the two projects separate so as not to pollute the project with support files, configurations etc from the old. This could be a real pain in something like iOS.
  4. Move the bits from the old project that I am reusing code from into the new project as I need it.

Unless the projects are SUBSTANTIALLY similar I find that cherry picking is a lot easier than trying to unload all the unnecessary baggage from the old project.

No special Git tools are required for the strategy I just outlined.

Cliff Ribaudo
  • 8,932
  • 2
  • 55
  • 78
0

Perhaps this is less of a version control problem and more of a refactoring one. It sounds like there may be enough shared code to pull out common functionality to its own project, which you could reference (by git-subtree or git-submodule) in the others. This way, if you do make fixes/improvements to the shared code, all your projects could benefit.

Greg Haskins
  • 6,714
  • 2
  • 27
  • 22
  • Would `git-subtree` or `git-submodule` automate the download of the dependent shared code and allow to commit changes to it? – dronus Aug 16 '12 at 13:56
  • Yep! `git-submodule` creates a clone of the entire repository, which you can commit/push/pull as normal. That's what I generally use, but I've read that `git-subtree` can work similarly. – Greg Haskins Aug 19 '12 at 00:19
  • There are some debates about `git-submodule` as well as about `git-subtree` but I will try them. – dronus Aug 19 '12 at 23:53