How about the following model. When one makes a PETSc branch zzz that will
A) use a frozen form of another package -- then moab.py (or AAA.py) points to
either a release or a commit-hash
B) use another package that will be updated/fixed based on the work in the
PETSc zzz branch. — then they
1) make a branch xxx in that other package
2) make moab.py point to that branch xxx in the PETSc branch.
C) Note: moab.py (or AAA.py) can never point to master or next of moab. It can
only point to a commit-hash or a development branch.
This will give me all the capabilities I want.
Jed, yes I know one cannot bisect back through the two branches together, but
you can’t have everything.
The only tricky time is when zzz gets merged into PETSc master or next. At that
time presumably we want the merged moab.py to point to the commit-hash of the
xxx branch in moab. Can this be automated, of course because anything can: if
yyyy.py package points to a branch when merged into next or master (or any
branch) the branch gets switched to the commit-hash of the head of the branch?
Now translate to git language.
Barry
On Jun 16, 2014, at 5:19 PM, Satish Balay <[email protected]> wrote:
> On Mon, 16 Jun 2014, Jed Brown wrote:
>
>> Satish Balay <[email protected]> writes:
>>> With hg-subrepo - one would do:
>>>
>>> hg update [commitid] to get a consistant snapshot of petsc+moab
>>
>> git submodule is similar, but it would be crazy to add every optional
>> external dependency as a submodule to petsc.git.
>
> [I was thinking in terms of collabortive development petsc+moab - and
> not 'package-management' for users.]
>
> So currently its 2 repos - in the future it could be more.
>
> However 'submodule' is a new tool - so it needs learning. I don't know
> all caveats. [for eg: location of the submodule cause problems? Will
> the submodule always get cloned even if the user is not using it?
> Will all petsc git users have to be aware of submodule? git commands
> in subrepo behave differently than in petsc repo.. ]
>
> Perhaps petsc configure:giturl [with --download-package] is preferable.
>
> One difference though:
>
> with submodule 'git commit' would probably automatically track the
> hashes between repos. But with configure:giturl - this has to be
> manually added to moab.py. Not a big deal..
>
> [we would also have to fixup configure:giturl to do 'git fetch; git
> checkout commit-id' for each configure run..]
>
> Satish
