Managing openbmc with subtree

[Dave Cobbley]

Brad,
Trying to identify the appropriate work-flowfor using git subtree to 
maintain all the meta-data under openbmc.
I'm imagining something like:

17 subtrees
** indicates an actual folder, not subtree.
meta-openembedded/
meta-raspberrypi/
meta-virtualization/
poky/
**meta-openbmc-machines/
** meta-arm
    ├── common
    └── meta-qualcomm
**meta-evb
    ├── meta-evb-aspeed
    ├── meta-evb-nuvoton
    ├── meta-evb-raspberrypi
**meta-openpower
    ├── meta-ibm
    ├── meta-ingrasys
    ├── meta-inventec
    ├── meta-rackspace
**meta-x86
     ├── meta-intel
     ├── meta-mellanox
     ├── meta-portwell
     └── meta-quanta
**meta-openbmc-bsp/
     ├── meta-aspeed
     ├── meta-ibm
     ├── meta-nuvoton
meta-phosphor/


I began working on the workflows that a typical dev would do to check 
code in and have Jenkins automatically update the top level repo with 
the new additions, but run into troublewith a merge commit.

1. git clone openbmc-openbmc
2. #make changes
3. git add
4. git commit...
5. git subtree push --prefix=path/to/local/subtree 
ssh://openbmc.gerrit/openbmc/<subtree_name> HEAD:refs/for/master

At this point, the build CI would run it's normal operations and code 
review would take place.
Following a +2 and submit, Jenkins would:

1. cd openbmc-openbmc
2. git pull
3. git subtree pull --prefix=path/to/subtree --squash <remote> master 
#For all given subtrees

However at this point, I end up with two commits in the parent repo, one 
with the squashed changes, and a merge commit.
I don't know how to do this operation without ending up with a merge 
commit, do you have any advice here?

I could be totally overthinking the whole strategy, so any advice and 
direction is much appreciated!
Along those same lines, is subtree still the correct tool? I hear repo 
works for a lot of projects, Yocto uses 
https://wiki.yoctoproject.org/wiki/Combo-layer.

Thanks,
-Dave