Barry Smith <bsm...@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). 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.
pgp2jwRl8qN3K.pgp
Description: PGP signature
