[petsc-dev] Updating MOAB version during download

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> writes:
>> 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).

What about rather than "git commit" doing this, have configure do the
modification when you have gone into PETSC_ARCH/externalpackages/moab/
and checked out a branch (rather than a commit).

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

That is *our* convention, but might not be *their* convention.  It's
none of PETSc's business to impose or assume workflow for a third-party
package.

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

I don't want PETSc to track the branch.  So if you want to checkout a
branch and make commits, *you* should do the checkout, not configure.
Configure can deal with cloning the repository.  The workflow for
getting your patch upstream is none of PETSc's business.  For example,
some projects review patches sent to mailing lists, in which case the
commit hash changes when it is committed (and the patch might also need
to be amended before being accepted).  In that case, you as contributor
cannot predict the hash that ultimately makes it into the repository.
It is wrong for gitcommit in PETSc to point at that commit hash that
will never make it off your computer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140617/85c8af5a/attachment.sig>