On Mon, 16 Jun 2014, Barry Smith wrote:

> 
> On Jun 16, 2014, at 4:31 PM, Jed Brown <[email protected]> wrote:
> 
> > Barry Smith <[email protected]> writes:
> >>   Jed has pointed out that a “branch” is not enough information, so
> >>   what should we use in the xxx.py so that the correct thing is built
> >>   when I build PETSc with a particular branch???
> > 
> > The commit hash, which is exactly what we have now.
> 
>   1) It is a manual beasty that someone has to edit moab.py and change on a 
> regular basis? This doesn’t work as proved by the current fiasco.
> 

I disagree. The problem stated previously was wrong - 'petsc-dev should track 
latest moab-dev'

If we stepback and state the workflow problem - and agree on the workflow - 
updating hash
is part of the workflow could be done.

If automatic tracking is critical - then we should look at 'git submodule'


>   2) It does not give me access to the branch so that I can make changes. Say 
> I am working on feature-dmmoab in PETSc and see a little bug in the moab 
> branch that (indirectly only since I am at some stupid headless commit-hash 
> instead on a branch) I am pointing to, that if I quickly fix I can push and 
> make life easier for my entire team of eight developers. I need to manual 
> figure out what branch corresponds to the commit-hash thing I had checked 
> out, change to that branch in moab, fix the branch in moab, push it and then 
> comeback and edit moab.py in PETSc to point to the new commit-hash beasty of 
> the moab branch.

We don't that luxuary of finding a bug in petsc [from nightly builds]
and quickly fixing it in the appropriate branch anyway. We have to run
a couple of git commands to do the appropriate thing. I would expect a
smilar thing with moab would be fine. [its just that its more of a
black-box to us petsc users wrt branch org]. But I don't see why
--downlaod-package should be burdened with keeping track of 'git
branches' which git doesn't track anyway.

Satish

> 
>     This is why I keep circling back to “branch” instead of commit hash in 
> the moab.py; 
> 
>     So somehow I would like the moab.py to “know” about the associated moab 
> branch (if there is one) as well as a commit-hash. Now when I checkout the 
> PETSc feature-dmmoab I want the branch checked out (at a particular 
> commit-hash? Is that possible?) Now if I update the moab branch with a new 
> commit then when I commit my feature-dmmoab I want it to automatically update 
> the “commit-hash” in the moab.py 
> 
>    Manually expecting people to switch from a commit-hash to its 
> corresponding branch in the moab repository and to ALWAYS put the right 
> thingy in the moab.py is totally fucking unrealistic. It is not a practical 
> workflow.
> 
>    You might think this is all academic nonsense and not to worry about it 
> but say I am doing a project that involves 3 repositories PETSc, moab, and 
> saws and have a branch in each that coordinates with a branch in each of the 
> others (and I am changing code in all three of them) and I am doing this with 
> a team of five people. Expecting all five people to always do the right thing 
> in coordination without automated help is impossible. So where does the help 
> come from, some git feature, some other tool????
>  
>   Barry
> 
> 
> 
> 
> 
> 
> 

Reply via email to