Re: Understanding the GIT organization and workflow for EPICS 7

[Andrew Johnson <anj@aps.anl.gov>]

On 02/28/2018 02:57 AM, Bruce Hill wrote:
> I'm still trying to figure out a good workflow for introducing local
> build changes and other local commits.    I'm finding the first step
> is to create your own local branch.
> git co core/master
> git co -b core/slac-master
> 
> Once this is done you at least have a branch where you can save
> and manage local commits without making commits on core/master
> that you'll later regret when you want to pull the latest core/master
> updates.

What I have started to do here is to create a new local git repo (on our
gitlab server) starting from the release tarfile. There is no connection
between the EPICS development repo and our internal one that we will be
using for production builds, so there is no danger of commits getting
pushed to the wrong places by mistake. It shouldn't be possible have
both our production repo and any EPICS community repo as remotes of the
same git working directory tree, and while I haven't tried it myself I
hope the result would be to generate a huge bunch of conflicts, which
should stop someone in their tracks before they can do any damage.

What I haven't tried to do yet is to import a new release into the same
repo (like importing a new version onto the vendor branch in CVS) but
there are various descriptions online from other people who have done
this with so I'm not too concerned about it.

> I also modified my core/slac-branch .gitmodules file to list our SLAC repos,
> although I think that can also be done by changing your config settings
> submodule.modules/pvAccess.url, etc .   Still experimenting w/ this and
> how to control which version of each submodule is checked out, as we
> often would want to build the latest tagged release of pvAccess or pvData
> instead of their master branch.

By starting from the tarfile I have a completely separate structure for
my Base repo that has no git submodules at all. All my version tags are
local too, so I have complete freedom to label things as I want to.

> I haven't figured out how to checkout a tagged module in one step from
> TOP, but
> these steps work for me so far.

Beware that you only really have one namespace for git tags (which gets
shared across all remotes and branches you have fetched), although as
long as you don't explicitly push your tags your local ones shouldn't
escape. With our current git submodule setup having 4 different modules
inside the same repository though you can't actually tag the submodules
with the same tag name as the core.

- Andrew

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon