On Jun 28, 2013, at 5:33 PM, Jed Brown <jedbr...@mcs.anl.gov> wrote:
> 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. Not at all! It is EXACTLY the workflow we expect to see as PETSc and MOAB become best buds. Someone branches off of PETSc master and moab master and make related changes to __both__ of those branches over time (likely a small team of people is working on these branches or branches of these branches). For example making another PETSc hook into moab that requires some additions to the moab base code as well as additional PETSc code*. When they are all done the two branches are eventually (and at the same time) merged into PETSc master and moab master for everyone to benefit from. Now I originally proposed doing this by simply requiring these people (who are presumably somewhat competent) to simply manually make sure the branches in the two packages match up appropriately (with perhaps a naming convention) as they do other stuff and checkout other branches then go back to work on their combined PETSc moab project they manually make sure the appropriate branch is set for each package. Jed implied that the manual matches of branches I proposed could be handled somewhat automatically (mumbling about gitcommit; I didn't understand what you proposed). My response is that __IF__ it can be handled somewhat automatically then it should be handled properly automatically; hence I asked if it could be handled completely generally automatically (checking out matching partners automatically) and your response was it is nebulous, complicated and unnecessary. But then you pushed gitcommit again. How can gitcommit help me manage the two synchronized work branches (especially when you say gitcommit shouldn't be a branch but a specific commit). It seems like the gitcommit business is completely orthogonal to the managing two synchronized branches business? Barry * Note that this is different from how we work with hypre, superlu etc etc where we just _use_ whatever crap is in hypre, superlu etc and only modify PETSc (except for fixing bugs in the other package we don't change the other package). When working with PETSc and MOAB we will be updating both packages in sync.
