[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