Git promotion/merging approach with 3rd party product

Question

I realize this is a very specific question, and some things might make even the hardened git user shudder, but bear with me…

We're implementing a virtual data warehouse, which generates metadata (SQL-like code). The product (Denodo) can be connected to VCS (e.g. git) to keep the changes under version control.

Internally, there are virtual databases and Denodo also organises its code into folders corresponding to these databases. Thus, in git you'll get something like:

Root
 \- Orders
 \- Customers
 \- Invoices

Underneath each of those database folders, there will be a several code files that make up the metadata.

Committing and pushing your code within Denodo is always done on database-level, even though the git repo has no such distinction and a commit is global for the repo.

Developers work locally on their individual databases and will periodically commit code changes. All these changes are pulled into the development server. So far so good.

Sooner or later, changes introduced into development need to find their way into QA and production. However, if we were to merge the current status from our development branch (develop) into our QA branch (release), we might get some unwanted (breaking) changes which weren't ready for prime-time yet.

Thus, we need to cherry-pick. And using git log, we can see which commits are yet to be promoted to QA. But if we cherry-pick individual commits from the develop branch into the release branch, they will get a new SHA, and next time we do a git log to perform a comparison, the previously cherry-picked commits will still appear.

Also, remember that the repository is organised by database. That also means that:

• I have report the commits made in each database-related folder
• Decide the last commit for each database to be promoted
• For each database: cherry-pick the oldest commit since the last merge up to the one selected in the previous step.

This range is not necessarily sequential. You might have something like this (ordered by date).

| To be promoted | Commit | Database  | Change              |
|----------------|--------|-----------|---------------------|
|                | da39a3 | Orders    | Created views       |
|        X       | ee5e6b | Customers | Bug fix             |
|        X       | 4b0d32 | Invoices  | Removed data source |
|                | 053e2d | Invoices  | Updated credentials |
|        X       | 956018 | Orders    | Created data source |

In this example, we'd cherry-pick commits ee5e6b (customers), 4b0d32 & 053e2d (invoices) and 956018 (orders). The reason I have to pick 053e2d for orders as well, is that the latest metadata may built upon changes checked-in earlier (due to intra-database dependencies). There are few to none inter-database dependencies.

Requirements:

• Each time there's a promotion planned, I have to be able to present an overview of commits which are in development but not in QA.

• I have to be able to select certain changes (up-to) on database level, that can be merged to the release branch for promotion to QA.

Limitations:

• The commits happen from within Denodo and VCS support isn't all that great (e.g. changing branches is not really supported). This also means that we can't implement feature branches in order to isolate breaking changes or long-term development.

• While we evaluate what to promote on database level, those commits aren't sequential.

My apologies for the long-winded question, but this isn't exactly a typical scenario and needed a bit more context. I'm also no git specialist (not by a long shot), so please, no pitchforks or torches. Thank you!