Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · Fri, 15 Dec 2017 10:14:38 +0100

Hello Andrew,

Thanks for the hint about the .ci directory. I had not noticed it yet.

I think this situation occurs regularly when updating RELEASE_NOTES.html

after a change in a submodule. How is the policy for this? I assume

RELEASE_NOTES.html should be updated for every new feature, right?

I am still quite new with git and have never used submodules before,

thus it may seem complicated only to me. But I found out that with git

guessing the next step is usually a bad idea. I often guess wrong and

and up with a headache and git status I cannot resolve.

When you say "set the right submodule branch" that means not core/master

but what I find in .gitmodules under "branch"? So for database it would

be modules/database but for pvDatabase just master?

When making a merge request, do I need a separate repository for each

feature or do I use separate branches on the same repository, e.g.

git+ssh://[email protected]/~dirk.zimoch/epics-base ?

What if I have a merge request of the same feature for multiple versions

of EPICS base, say 3.15, 3.16, and 7?

Dirk

On 14.12.2017 18:02, Andrew Johnson wrote:

Hi Dirk,

If you're likely to be making changes across multiple modules you can
also use the checkout-modules.sh script in the core's .ci directory
which for each submodule will checkout and pull the branch named in the
.gitmodules file for that module. I haven't tried using it when I have
made local commits that haven't been merged yet though, it may prompt
you for a log message in that case.

You are also leading the way with your question about how to do merge
proposals with the new structure. Unfortunately I think we may have made
this much more complicated for some developers, although as long as your
changes only affect one submodule it shouldn't be too bad. You just have
to make sure that you set the right submodule branch that you want to
merge the change into when you're submitting the proposal to Launchpad.

I do want to have a discussion about the process in the new year, we
need to properly document it, which we previously did on the Wiki page
https://wiki-ext.aps.anl.gov/epics/index.php/How_to_check_out_EPICS_Base_with_Bazaar

There are probably many things out of date that are linked from the V4
page http://epics-pvdata.sourceforge.net/development.html

- Andrew

On 12/14/2017 10:21 AM, Michael Davidsaver wrote:

On 12/14/2017 08:48 AM, Dirk Zimoch wrote:

Hi everyone,

What I still do not understand is how to work on the EPICS 7 submodules.

On 14.12.2017 14:38, Michael Davidsaver wrote:

I avoid the redundant download with:

git clone --branch core/master https://github.com/epics-base/epics-base.git
git submodule update --init --reference .

Note that the second line ends with a dot '.'.

After that, what is the state of the submodule? Latest commit? I found that git tells me that they are "not on any branch". Is that a problem?

When 'git status' reports no changes in the super-module, then each of the submodules are at the commit associated with the super-module
commit.  This will often be a detached HEAD (aka. not on any branch).  This is fine if you're just going to build.  If you want
to do work, then generally the first step is to go into a submodule (eg. modules/ca) and create a branch.  eg.

cd modules/ca
git checkout -b mybranchname

This will create a new branch at the present rev without modifying the working tree (it's safe).
You can then move that branch around as necessary.  eg.

git merge --ff-only origin/ca/master

Which is the safe way to jump to the latest rev.  If will abort if the current branch has diverged,
or if uncommitted changes would be clobbered.

So when I want to propose a change for merge, what should I do?
Create a new branch I suppose but in the submodule or in the main directory?

If you're only changing one submodule, then go into the submodule directory and forget about
the supermodule while you're working.  To continue my modules/ca example:

cd modules/ca
git checkout -b mybranchname
... file changes ...
git commit -m 'Make CA great again"
git remote add md https://github.com/mdavidsaver/epics-base.git
git push md mybranchname

Then pushing the merge request, will I push from the submodule or from the main directory?

The whole work flow with submodules is still very unclear to me.

Dirk

On 12/14/2017 02:20 AM, Torsten Bögershausen wrote:

Hej,
Yesterday I was sitting on a 3Mbit/sec line I was cloning base from Git,
I realized that "base" needs to be transferred 4 times.
I got 4 pack files, each 95M.
One for base, modules/ca, modules/database, modules/libcom/

99 234 251 ./.git/modules/modules/ca/objects/pack/pack-08cf7dbc8f8108176628acb637cfa5d864f0aa43.pack
99234251 ./.git/modules/modules/database/objects/pack/pack-08cf7dbc8f8108176628acb637cfa5d864f0aa43.pack
99234251 ./.git/modules/modules/libcom/objects/pack/pack-08cf7dbc8f8108176628acb637cfa5d864f0aa43.pack
99234251 ./.git/objects/pack/pack-08cf7dbc8f8108176628acb637cfa5d864f0aa43.pack

I think this is because the modularization was done without running
"git filter-branch".

My first question:
Does anybody else feels that this is a problem to download
4*95 Mbyte, when 1*95 Mbyte enough ?

And if yes, what should we do about it?
a) Undo the modularization.  Keep ca, database, libcom in the same
   Git as before ?
b) Run Git filter-branch and try a surgery on the Gits?
c) Leave everything as it is ?

Any thoughts and opinions ?

On 01/12/17 01:20, Andrew Johnson wrote:

I just tagged, tarred, tested uploaded and pushed the -rc1, but I don't
have time to write the announcement email for tech-talk tonight. If no
one else feels like doing so I'll get to it tomorrow morning.

- Andrew

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System