Thanks for the recipes.
I find working with git submodules takes more of my time than the actual
programming. Is it worth it? Why not having all EPICS 7 in one repo?
This looks so error prone to work with.
I do not use linux-x86 because we have so many Linux versions. Our
original linux-x86 was built for RH7.3 long ago and is still around. To
minimize breaking stuff by re-using the same name for something
different I use a specific EPICS architecture for each Linux version. So
at the moment I have RHEL7-x86_64, which of course simply includes the
For Jenkins I could change that but so far I simply copied my standard
Once my current compilation succeeds, I will create and send a diff.
On 29.11.2017 18:51, Andrew Johnson wrote:
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,
$ 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
$ 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
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.
- Re: git problem J. Lewis Muir
- git problem Dirk Zimoch
- Re: git problem Andrew Johnson
- Navigate by Date:
Re: SIML type CA and PINI=YES issue Kasemir, Kay
Re: SIML type CA and PINI=YES issue Ralph Lange
- Navigate by Thread:
Re: git problem Andrew Johnson
Re: git problem J. Lewis Muir