[petsc-dev] Updating MOAB version during download

Jed Brown jed at jedbrown.org
Mon Jun 16 22:03:17 CDT 2014


Barry Smith <bsmith at mcs.anl.gov> writes:
>> This is way more involved and error-prone.  Git submodule and hg subrepo
>> aren't really designed for this use case (they work better when the
>> package is developed separately and you occasionally update) and I don't
>> think it's something we should try to do.
>
>    I never suggested using git submodule or anything like that.

You asked for something that automatically does what you mean.  I
mentioned those systems as evidence that what you are asking for is hard
(has ambiguous semantics because "do what I mean" ends up being
extremely context-sensitive).

>    But when I get my first dump of stuff from moab I don’t need to
>    know any of that stuff (i.e. when I do —download-moab) and when I
>    later decide I want to contribute a fix why should I have to go
>    back and manually do a new clone and checkout etc. I just want to
>    use the one I already got when I did —download-xxx
>
>    I am confused because I had assumed this was why you added git
>    support to —download-xxx. Now you are telling me that I should
>    ignore the fact that —download-xxx gives me a git repository and I
>    should go and get it manually with git?

I added gitcommit so that we could easily update the version that we
need.  If you want to use it as a general git repository for
contributions, you can use that repository, but I want you to be on your
own (because I think anything we try to do will have complicated failure
modes and end up not being better in the long run).
-------------- 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/20140616/6bbbd608/attachment.sig>


More information about the petsc-dev mailing list