# autopacking twice? 4 messages from 2014-06-22 to 2014-06-23. Participants: Michael S. Tsirkin, Matthieu Moy, Duy Nguyen. Thread: https://gitlist.dev/t/36977 ## Michael S. Tsirkin, 2014-06-22 05:51 Subject: autopacking twice? Message-ID: <20140622055154.GA13819@redhat.com> URL: https://gitlist.dev/e/20140622055154.GA13819%40redhat.com ``` 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 ``` ## Matthieu Moy, 2014-06-22 15:22 Subject: Re: autopacking twice? Message-ID: URL: https://gitlist.dev/e/vpqbntlq893.fsf%40anie.imag.fr In-Reply-To: <20140622055154.GA13819@redhat.com> ``` "Michael S. Tsirkin" writes: > Guess: auto-packing was started in background, did not > complete in time, and was restarted for the second time? Probably once for fetch, and another after rebase. > If true, some kind of lock file would be useful > to prevent this. It is the case with recent versions of Git (>= 1.8.5). Which version are you running? -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ``` ## Michael S. Tsirkin, 2014-06-22 16:43 Subject: Re: autopacking twice? Message-ID: <20140622164357.GA31997@redhat.com> URL: https://gitlist.dev/e/20140622164357.GA31997%40redhat.com In-Reply-To: ``` On Sun, Jun 22, 2014 at 05:22:32PM +0200, Matthieu Moy wrote: > "Michael S. Tsirkin" writes: > > > Guess: auto-packing was started in background, did not > > complete in time, and was restarted for the second time? > > Probably once for fetch, and another after rebase. > > > If true, some kind of lock file would be useful > > to prevent this. > > It is the case with recent versions of Git (>= 1.8.5). Which version are > you running? Sorry, forgot to mention this: $ git --version git version 2.0.0.542.g41d13ef this is git master with some patches by my own. > -- > Matthieu Moy > http://www-verimag.imag.fr/~moy/ ``` ## Duy Nguyen, 2014-06-23 10:57 Subject: Re: autopacking twice? Message-ID: URL: https://gitlist.dev/e/CACsJy8D3cz9w9RrVLcRgz%2Bxgw0%2B2B9G_BAotvVzUoJ9Uf-Zoag%40mail.gmail.com In-Reply-To: <20140622055154.GA13819@redhat.com> ``` On Sun, Jun 22, 2014 at 12:51 PM, Michael S. Tsirkin wrote: > 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. 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.. -- Duy ```