I noticed this: remote: Counting objects: 302, done. remote: Compressing objects: 100% (195/195), done. remote: Total 209 (delta 169), reused 15 (delta 14) Receiving objects: 100% (209/209), 42.83 KiB | 0 bytes/s, done. Resolving deltas: 100% (169/169), completed with 67 local objects. >From git://git.qemu.org/qemu 6baa963..427e175 master -> origin/master Auto packing the repository in background for optimum performance. See "git help gc" for manual housekeeping. First, rewinding head to replay your work on top of it... Applying: vhost: block migration if backend does not log memory Applying: vhost: fix resource leak in error handling Applying: qapi/hmp: use 'backend' instead of 'device' with memory backend Applying: libqemustub: add more stubs for qemu-char Applying: qtest: fix qtest for vhost-user Applying: qtest: fix vhost-user-test unbalanced mutex locks Applying: e1000: emulate auto-negotiation during external link status change Applying: e1000: improve auto-negotiation reporting via mii-tool Applying: e1000: signal guest on successful link auto-negotiation Applying: e1000: move e1000_autoneg_timer() to after set_ics() Applying: e1000: factor out checking for auto-negotiation availability Applying: fixup! libqemustub: add more stubs for qemu-char Applying: qapi/string-output-visitor: fix human output Applying: tests: add human format test for string output visitor Applying: Revert "fixup! libqemustub: add more stubs for qemu-char" Applying: fixup! libqemustub: add more stubs for qemu-char warning: notes ref refs/notes/commits is invalid Auto packing the repository in background for optimum performance. See "git help gc" for manual housekeeping. Why did it auto-pack twice in a single pull? None of the changes applied are very large. Guess: auto-packing was started in background, did not complete in time, and was restarted for the second time? If true, some kind of lock file would be useful to prevent this. -- MST -- 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