Sharing Portions of Codebase

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a project written for a specific custom board, but a large portion of it is something I'd like to share with a project for another custom board.  Let's call the shared portion "Core" and the unshared portions "App1" and "App2".  I'd like any changes to Core to automatically propagate to App1 and App2.  I use git for revision control, and a submodule seems like it would be perfect for this, with Core as a submodule of both App1 and App2.  Unfortunately, I'm not sure how to do this while still preserving the directory structure Atmel Studio expects.  Most of Core is things like ASF generated files (some of which have been modified), and its contents would span many of the folders in the project directory.  This may expand to more than 2 projects in the future, so simply keeping it as a single project with the differences between App1 and App2 #defined in config files isn't a viable option for me.

 

Has anyone else found a good solution for a situation like this?

 

I can think of a couple ways to do it, but neither are really ideal:

1. Re-structure the project so that all of Core is in a single directory and make that the submodule - not great because it breaks the ability to add new ASF/Start modules

2. Use symlinks in the App1 and App2 projects to point to Core - Could get messy and wouldn't work like a true submodule

 

I'll be reading up on submodules and related tonight since I'm not really familiar with them yet, and I may be making some bad assumptions here.  I'm sure this is not a new issue though, just new for me.

 

TIA

 

Last Edited: Wed. Oct 16, 2019 - 08:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Having had git submodules inflicted on me in the last year or two I'd say run at 1,000 mph in the other direction.
.
On our internal Wiki I've even created a page simply to list for colleagues the many, many reasons I hate submodules!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hillridge wrote:
Unfortunately, I'm not sure how to do this while still preserving the directory structure Atmel Studio expects.
Neither do I.

GitLab has projects with custom templates though that feature is value-added (subscription per operator per month)

Custom project templates | Create a project | GitLab via Create | Features | GitLab

Might survey the other git enhancers.

 


https://about.gitlab.com/pricing/#self-managed

 

edit :

Group repositories into projects - Atlassian Documentation (Bitbucket)

https://bitbucket.org/product/pricing?tab=self-managed

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Thu. Oct 17, 2019 - 12:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here are just 4 points from my Wiki (suitably redacted!):

1) mis-placed cherry picks: You go to Gerrit to cherry pick a change onto a tree and copy the fetch instruction to the clipboard. When you then paste this to a command prompt it just so happens that the current directory is part of a submodule and not the core < main repo > tree. As that git repo does not have the < main repo > history it then attempts to download the entire < main repo > (and the cherry pick) into the submodule

 

2) Traceability. Something is wrong. You locate what you think is the reason and git blame it. That gives you an SHA for the change so you can go and look at what's behind it. You go over to Gerrit and type the SHA into the search box as usual and Gerrit tells you it does not know the SHA. That's because the file you happened to be looking at was within the tree of a submodule. At least it appears the < web interface for submodules > has a "search all of < this place >" so you can search all the projects for the commit . But finding the culprit can now involve multiple searches on different websites. BTW in researching this I found "git rev-parse --show-toplevel" to be useful. It will be "< main repo name > if part of the master repository but something else for a submodule.

 

3) History: It appears that when a tree within < main repo > is turned into a submodule all its previous history is lost. So after the move you cannot use git blame to determine who was responsible for some change that you are interested in finding more about or the SHA of where it was committed,

 

4) Updates: it is all too easy to pull an update ("git pull --rebase") to the main < repo > tree and miss the fact that now some of the submodules are out of sync thus requiring a "git submodule update --init–recursive". Why can't this be configured to just be part of the < main repo > update or, if it cannot, it is EXTREMELY irritating. 

And don't talk to me about how you make (hopefully atomic) updates that span the boundary between the main repo and the submodules. The procedure is tortuous.

 

The supposed "gain" of submodules is modularity - you can now share that same module into another main repo - but apart from that, as long as you are methodical about the organisation of the main repo I don't see how it really benefits to split a Git repo. It sure makes my life hell. Just have "core" and "app1"/"app2" trees in the directory structure - you don't really gain anything by making "core" a submodule.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

The supposed "gain" of submodules is modularity - you can now share that same module into another main repo - but apart from that, as long as you are methodical about the organisation of the main repo I don't see how it really benefits to split a Git repo. It sure makes my life hell. Just have "core" and "app1"/"app2" trees in the directory structure - you don't really gain anything by making "core" a submodule.

 

I'm not sure I follow what you mean by "Just have "core" and "app1"/"app2" trees in the directory structure".  I need some form of modularity, as there may be an App3,4,5... in the future and I think having it all in one repo would get messy.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
src\core
   \app1
   \app2
   \app3
   ...

Simple as that.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

repo?

Subprojects or sets of repositories | Interfaces, frontends, and tools - Git SCM Wiki

...

repo is a project to use Git to build OS distributions; similar to Git submodules, it can track specified branches from Git projects.

https://source.android.com/setup/develop#repo

...

An MCU application can be a collection of framework or RTOS parts (scheduler, queues, pools, stacks) plus selected or total pieces (device drivers, tests, state machines, "main")

 

"Dare to be naïve." - Buckminster Fuller