Re: Managing openbmc with subtree

[Dave Cobbley <david.j.cobbley@linux.intel.com>]

The closest paradigm I can figure is this:

               +---------+                   | +-------------+
               |   Dev   |                   |               | Jenkins   |
               +---------+                   | +-------------+
+--------------------------------------------------------------------------------------------------------------+
    1. Modify subtree                        |
    2. git add/commit                        |
    3. git push gerrit HEAD:refs/for/master  |
                                             |   Once +2 is given
                                             |   4. git subtree pull 
--prefix=path/to/subtree <subtree> master
                                             |   5. git checkout <ref>
                                             |   6. git reset --soft ~1
                                             |   7. git commit <with 
message from original author>
                                             |   8. git add/commit
                                             |   9. git push
    10. git pull --rebase                    |
                                             |
                                             |
                                             |
                                             +

It seems wrong to do a reset --soft. Git must have a better way of doing 
this with subtrees.

Thanks,
-Dave


On 07/19/2018 01:08 PM, Dave Cobbley wrote:
> 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