[petsc-dev] Branch 'next' has been rewound

[Jed Brown]

Matthew Knepley <knepley at gmail.com> writes:

> On Mon, May 13, 2013 at 8:48 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
>> == Users ==
>>
>> I have rewound the branch 'next' after the release, so it will
>> not fast-forward (just this once).  If you have a local 'next' branch,
>> you should abandon it and check out a fresh one.  You can do this with
>>
>>   $ git checkout master
>>   $ git branch -D next   # delete the old branch
>>   $ git pull
>>   $ git checkout next    # revisit 'next' if you want
>>
>> If you are tracking 'master', 'git pull' will be sufficient.
>>
>>
>> == Developers ==
>>
>> With v3.4 tagged, we can decide what to do with the branches left over
>> from 'next' (now in a temporary 'next-pre-3.4' that will be deleted).
>> If they should be rebased, it's best to do it now.
>>
>>   $ git checkout my/branch
>>   $ git rebase v3.4
>>   $ git push -f --dry-run # should show force-update to your branch only,
>> then remove '--dry-run'
>>
>> If you like everything in the branch, but there are conflicts, you can
>> sync with v3.4 now [1].
>>
>>   $ git checkout my/branch
>>   $ git merge v3.4
>>   $ git push
>>
>>
>> Here is a status summary for the branches that used to be in 'next':
>>
>>
>> e8577e4 2013-04-10 (karlrupp/feature-viennacl) ViennaCL: fix LOCDIR
>>
>>   This has a simple conflict with 'knepley/remove-sieve' (below) in
>>   src/vec/vec/interface/vecregall.c
>>
>> b61a8fb 2013-03-15 (klaij/fieldsplit-simple-ex70) SNES ex70.c: free array
>> returned by PCFieldSplitGetSubKSP()
>>
>>   This example highlights a bug/feature request in fieldsplit.  If it
>>   can be handled without interface changes, it should go to 'maint'.
>>
>> a05fad5 2013-05-12 (knepley/remove-sieve) DMPlex: remove bad "DMMESH"
>> documentation
>>
>>   This branch is a bit chaotic and could reasonably be rebased and have
>>   the incomplete commits squashed together.
>>
>> 1cf896f 2013-03-22 (knepley/solkx) SNES ex75: Added Maple verification
>> test, and added preliminary FEM test
>>
>>   This branch contains one commit (a9ffcdab03f) that is unrelated and
>>   made it into v3.4 in a different form (3e298deff27), so rebasing would
>>   make it cleaner.
>>
>
> These two have been rebased and pushed.

You didn't use 'push -f' as in my instructions above, so you created a
new merge commit containing both the old and new versions of the
commits, instead of replacing the old commits with the rebased versions.