Announcement

Collapse
No announcement yet.

Workaround for losing GIT history of TeamCode module when migrating to SkyStone SDK?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Workaround for losing GIT history of TeamCode module when migrating to SkyStone SDK?

    With the creation of a new SkyStone repository, there is a fresh clean TeamCode module. We have 3 years of GIT history in our TeamCode module from the old SDK. I believe that just doing an OS copy of the contents of the TeamCode module from the old SDK to the SkyStone TeamCode directory will lose that history. We also have about 20-30 branches in that TeamCode module. Is there some way to migrate our TeamCode, with its history and branches intact, into the SkyStone TeamCode? I've looked into several posts on the web but not found anything similar to this situation.

  • #2
    Personally I'm happy about the change since it means the repository size isn't 1GB anymore, haha. That being said, I can understand where you're coming from.... However, I make a new repository every season since so much of my code is game/robot specific. If you have a large amount of code that you reuse year-to-year (maybe encoder localization / path planning or something) my suggestion would be to migrate that to an entirely separate repository and use that as a git sub-module in your year-specific repository.

    That being said, to answer your actual question, I'm sure there's a way to do it, probably involves forcing the merge of unrelated histories, but I personally don't know how to do it off the top of my head.

    Comment


    • #3
      This description of a solution is relatively straight forward and worked when I tested it by migrating 9794's, thanks Wizards!, TeamCode directory into a new SkyStone repo.

      http://gbayer.com/development/moving...rving-history/

      Now I just moved a single branch, master, following the instructions therein. If you point me at your repository, I'll do some experimenting on a local clone with your other branches.

      You should however consider, since you need to migrate anyway, moving your software such that it's managed external to the sdk's workspace. A little gradle magic makes this pretty easy to do. See for example https://github.com/cmacfarl/SkyStone...d1ccd4c0dba5b5 which pulls in source from another repository that lives beside SkyStone in the filesystem.

      Comment


      • #4
        Originally posted by skatefriday View Post
        This description of a solution is relatively straight forward and worked when I tested it by migrating 9794's, thanks Wizards!, TeamCode directory into a new SkyStone repo.

        http://gbayer.com/development/moving...rving-history/

        ...
        Nice, but since there will be a new FTC SDK repo next season, you have to perform this surgery again every season.

        4634 Programmer 's suggestion is a better solution since sub-modules was designed for this purpose. Keep your team code in a dedicated team code repo and simply sub-module your team code repo to your team's fork of the season specific FTC SDK repo. I suggest that you sub-module your team code repo at
        TeamFORK/TeamCode/src/main/java/org/firstinspires/ftc/teamcode/External

        Comment


        • #5
          Originally posted by Alec View Post

          Nice, but since there will be a new FTC SDK repo next season, you have to perform this surgery again every season.
          Right, which is why I closed with a possible alternate solution. There are half a dozen different ways to accomplish this. Pick your poison so to speak.

          Comment


          • #6
            Originally posted by skatefriday View Post

            Right, which is why I closed with a possible alternate solution. There are half a dozen different ways to accomplish this. Pick your poison so to speak.
            Sorry, I didn't look very closely at your alternate solution. Yes that's a good solution for projects managed by gradle. Git sub-modules are a general solution though.

            The important thing is for kids to get used to the concept of code/libraries spanning multiple repos. Another benefit of keeping team code in a separate dedicated team code repo is that it eliminates accidental pull requests to the FTC SDK repo.

            Comment

            Working...
            X