Experimental Physics and
Industrial Control System

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

On 15.12.2017 09:57, Ralph Lange wrote:

Upstream repository is Git on Launchpad, GitHub clone is synchronized
via a mirroring job.
As mentioned on the GitHub page, no recent changes.

~Ralph

Thanks. I asked because I was not sure if github or launchpad is the

correct place for merge requests or if both are ok.

Dirk

On Fri, Dec 15, 2017 at 9:48 AM, Dirk Zimoch <[email protected]
<mailto:[email protected]>> wrote:

    Hi Michael,

    Thanks for the explanations.

    I noticed that you used github in your example, not lauchpad. Has
    this changed recently?

    Dirk

    On 14.12.2017 17:21, 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
                    <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
            <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