Re: Understanding the GIT organization and workflow for EPICS 7

[Michael Davidsaver <mdavidsaver@gmail.com>]

On 02/28/2018 11:55 AM, Andrew Johnson wrote:
> 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.

This is the common practice in the world of debian packaging as well.
An "upstream" branch is maintain where each rev. corresponds
to the unmodified upstream source.  Then a "master" branch
contains any changes.

> 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,

It is.

> 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.

"git push" will complain the the current remote branch isn't an ancestor
of the one you're trying to push.

> 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
>