On Mon, 16 Jun 2014, Vijay S. Mahadevan wrote: > > It is not the "default", it would be in certain branches, the issue > > comes up when those certain branches are merged into master. Then does > > master somehow lock onto the current commit of moab so that further changes > > don't break master. (Meanwhile other petsc branches may be tracking the > > further moab changes) > > > > You are not thinking properly in terms of multiple petsc branches that > > may be tracking branches in other packages git repositories. How do we > > handle that with master and next? > > Barry, I like this capability of tracking different dependency branch > based on the current feature branch but what gets confusing is when > you merge onto master or next. This assumes that if dmmoab-feature-1 > tracks v4.6.1 and dmmoab-feature-2 tracks v4.6, then dmmoab-feature-2
Here I'm assuming you mean: in 'dmmoab-feature-1' moab.py has url=v4.6.1 [this url was updated either in dmmoab-feature-1 or a prior commit in master] in 'dmmoab-feature-2' moab.py has url=v4.6 [this url was updated either in dmmoab-feature-2 or a prior commit in master. But mostlikely its already in master] > cannot be merged before dmmoab-feature-1 unless moab.py is changed > appropriately ? It should be fine for almost all use cases but just > trying to understand this statement better. If I understand this correctly - 'git merge' should take care of it [either merge it automatically - if there is a conflict - prompt you to resolve it ] The order of merges shouldn't matter. [at the end of merge url=v4.6.1] Satish
