[petsc-dev] Updating MOAB version during download

[Barry Smith]

On Jun 16, 2014, at 9:50 PM, Jed Brown <jed at jedbrown.org> wrote:

> Barry Smith <bsmith at mcs.anl.gov> writes:
>>   If a pull request is made obviously the moab branch needs to be
>>   converted to a commit-hash for that review, then reviewers are
>>   looking at a stable “other package”. Or one just needs to freeze
>>   both branches until the review is complete.
> 
> You can't retroactively modify the petsc commits to use a moab hash.
> You have to use the moab hash all along.

   I have no problem with the moab.py also having a moab commit-hash at every commit of the PETSc branch (along with the moab branch name) so long as it can be done automatically and doesn’t require me to manually edit moab.py each time before I do a commit on the PETSc branch (because I will forget).

  So rather than having git merge put in the commit-hash only on merge to next or master how about having git commit put the latest commit-hash for the moab branch into moab.py at every commit? Can git do this automatically (or will you have to come up with some rationalization why no one would ever want git to do such a thing?). Note this is just automating what you said earlier we should be doing (with the addition that I want the moab branch name available also so I can can check it out without futzing around calling Tim to find out what it is :-(). 

> 
>>    If someone is pushing new commits on the moab branch associated
>>    with the petsc branch they are obligated to test them against
>>    PETSc so if I come in later and access the PETSc branch and the
>>    moab branch they will work together. One could not just pick an
>>    arbitrary moab branch (that people may be changing willy-nilly)
>>    and say my PETSc branch is tracking that rather it is a moab
>>    branch specifically associated with the PETSc branch. For example
>>    petsc-feature-dmmoab could be a branch in moab that is tracked by
>>    the feature-dmmoab branch in PETSc.
> 
> 1. This is special-cased for someone that simultaneously owns branches in
> both projects.

  Yes

> 
> 2. It assumes that there will be sufficient communication among other
> MOAB developers so that they know the branch has hidden connections with
> a different project and thus must be treated specially.

   Can be easily done with naming conventions, for example.  Regardless, normally people don’t go into other peoples branches and start changing shit unless there was some agreement to that they could do this.
'
> 
>>  Note that all this is the same regardless of whether one manually
>>  git clone ; check checkout the moab branch or used
>>  —download-moab. You just seem to have it in your head that Barry
>>  should be doing a lot more git clone xxx himself rather than letting
>>  —download-xxx do it for him.
> 
> I think you should be doing "git checkout -b barry/moab-branch" and
> dealing with getting it upstream.

   I have no idea what you mean by this.