[petsc-dev] moab nightlybuild failure

Satish Balay balay at mcs.anl.gov
Fri Jun 28 17:53:55 CDT 2013

On Fri, 28 Jun 2013, Jed Brown wrote:

> Barry Smith <bsmith at mcs.anl.gov> writes:
> >> petsc-branch:moab.py could name a commit on a MOAB branch, possibly
> >> updated on merge.
> >
> >    otherwise it is hopeless.  So each PETSc branch would have to have
> >    in it somewhere information about which MOAB "branch/commit" it is
> >    suppose to use and switching to (checking out) that PETSc branch
> >    means it will automatically switch to that moab branch (oh sorry,
> >    "checkout" to that moab branch).  In addition when the PETSc branch
> >    is merged to another branch the right information about the moab
> >    commit/branch that should be used needs to be put in the right
> >    places in that merged branch. Can you do this? 
> This is why MOAB has its own test suite.  A working branch can appear in
> PETSc while some work is being done in moab.  During that time,
> gitcommit can be set to point at the MOAB commit (could use a branch
> name here, but then it won't work later when that branch has been
> deleted; a commit is better because it's precise and eternal).

Not if the branch is rebased [and later garbage collected] - which can
happen with all working brances [but not master/maint]


>  This is
> basically the same model as git submodules and hg subrepos.  Merges are
> still tricky because they need out-of-band information and may not be
> achievable (if the branches containing the two commits have not been
> merged in MOAB).
> >    Surely git must have some unforgivably clumsy syntax somewhere to
> >    allow branches in two repositories to always meet their correct
> >    partners that the dance?
> I think the semantics you desire are nebulous to define in the general
> case.  It's a very complicated workflow and I think quite unnecessary.

More information about the petsc-dev mailing list