Matthew Knepley <knepley at gmail.com> writes: > Okay, so that way I make sure that stuff is not breaking is always to merge > into next. > > However, it still appears that the model for publishing features has the > costs > above. Maybe I do not see how you want it to go. Here is my situation: > > I have a knepley/pylith branch. I have this branch because I anticipate > that > new things required by PyLith will not come out in 'master' fast > enough.
What exactly is the purpose of 'knepley/pylith'? Is it to develop new features specifically for PyLith or is it to certify some combination of recent states that should work with PyLith? If it is to certify states, then I suggest just having 'knepley/pylith' mark a snapshot of 'next' that has been tested with PyLith. Your workflow would look like this: finish my feature (next) $ git pull # get changes from upstream (next) $ git merge knepley/new-feature-for-pylith run tests with PyLith, then (next) $ git push origin next next:knepley/pylith That is, you're pushing your local branch 'next' (that you just tested) to both 'next' and 'knepley/pylith'. PyLith then follows 'knepley/pylith', which is just marking the state of 'next' the last time you tested it with PyLith. Since it's always marking a point on 'next', it will fast-forward, so the PyLith user just clones PETSc, then $ git checkout knepley/pylith and from then on, they will get your latest tested state with (knepley/pylith) $ git pull Note that in the above, your workflow is exactly the same as if PyLith didn't exist, except that you add 'next:knepley/pylith' to pushes when you want to certify that a state in 'next' works with PyLith. Instead of 'knepley/pylith', you might call it 'next/pylith'. > However, > all things in here should eventually go into master. > > If master was integrated frequently, I have no problem. I will just use > that, but > that was not my impression. The alternative seems to be to pull in each > branch > individually that went into 'next', and which we think will go to master. > But what if > I am wrong and merge something that does not go into master? This would be a lot of work and would defeat the purpose.
