While using this series for real work today, I found another bug that is unfortunately a show-stopper for my workflow. Store 7 patches from David Turner to a file, ./+dt-7, starting at http://thread.gmane.org/gmane.comp.version-control.git/273786 and then: $ git checkout master...dt/refs-backend-preamble ... "git checkout 912bd49" is also fine ... $ git am -s ./+dt-7 This stops while applying 6th patch, like so: Applying: update-ref and tag: add --create-reflog arg error: patch failed: builtin/update-ref.c:431 error: builtin/update-ref.c: patch does not apply Patch failed at 0006 update-ref and tag: add --create-reflog arg The copy of the patch that failed is found in: /usr/local/google/home/jch/w/git.git/.git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". This is expected, but the recovery from this state is what goes wrong. At this point, one of the usual thing to do is to $ edit .git/rebase-apply/patch and match the offending preimage to what the working tree has. In this case, the conflict is found near the end of builtin/update-ref.c, where the call to delete_ref() in the pre-context of the hunk at around ll.413,+10 was return delete_ref(refname, oldval ? oldsha1 : NULL, flags); but in the newer codebase, the line is split further and the pre-context would show just flags); the latter of which is what $gmane/273793 expects. A fix is to edit the patch to replace that "flags);" line with full "return delete_ref()" line and save it. Then running $ git am (no argument) is supposed to read from the corrected patch file and continue the application. This no longer works with the version with this series, it seems. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html