On 11/29/2017 03:13 AM, Dirk Zimoch wrote:
How can I keep in sync with core/master including all submodules?
I have never worked with submodules (And my general git knowledge is
somewhat limited to clone, add, commit, push).
So how to work with the EPICS 7 git repo?
The new multi-module organization is more complicated to work with as a
developer. Here are some git commands I find useful.
After doing the initial "git clone --recursive" all the submodules are
checked out at the detached commit stored in the core/master branch. To
update all the submodules to the commit at the tips of their branches,
do this:
$ git submodule update --remote
To update the core module as well, do
$ git pull
I usually update the submodules first, but the order doesn't really
matter (if you do the pull first you might see some potentially worrying
error messages, but they aren't really errors in practice and git cleans
the tree up by itself before the pull finishes).
If you're going to work on and want to commit to one or more of the
submodules you have to explicitly check out the correct branch for each
module, and unfortunately they aren't all named alike (the top-level
.gitmodules file lists them all). e.g.
$ cd modules/libcom
$ git checkout libcom/master
but
$ cd modules/pvData
$ git checkout master
Git allows you to commit to your local branch and then push those
changes to a different repository than you normally pull updates from.
For some hints on that, take a look at my Triangle Workflows Gist at
https://gist.github.com/anjohnson/8994c95ab2a06f7d2339
One solution that occurs to me for the PSI configuration might be to set
INSTALL_LOCATION to point to an external directory tree where you have
already installed all your additional config files. These would be used
by all the submodules (but not by the core module itself, so if your
EPICS_HOST_ARCH isn't one of our standard ones this idea won't really
help you). You would only need to add a configure/CONFIG_SITE.local file
to your git working directory, and that file is already listed in Base's
.gitignore file. I haven't tried doing this, but if you can get it to
work it might be much simpler than explicitly setting up local branches
and having to do merges between them.
Maybe for testing purposes and for your Jenkins builds you could use the
linux-x86_64 host architecture? Just a thought.
- Andrew
