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.
