autopacking twice?

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.

"Michael S. Tsirkin" <mst@redhat.com> writes:

Probably once for fetch, and another after rebase.

It is the case with recent versions of Git (>= 1.8.5). Which version are you running?

On Sun, Jun 22, 2014 at 05:22:32PM +0200, Matthieu Moy wrote:

Sorry, forgot to mention this:

$ git --version git version 2.0.0.542.g41d13ef

this is git master with some patches by my own.

On Sun, Jun 22, 2014 at 12:51 PM, Michael S. Tsirkin <mst@redhat.com> wrote:

There is a lock, $GIT_DIR/gc.pid. However we are prepared to deal with stale locks, and may have slipped somehow. The test is in builtin/gc.c, lock_repo_for_gc(). Oh wait, we check for lock (and exit if lock exists) _after_ we print the message (in cmd_gc). That might be it.. If it so, maybe we can reorder some code to prevent this bogus message, but has to be careful and do it before daemonizing..