autopacking twice?

autopacking twice?

[Michael S. Tsirkin]

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

Re: autopacking twice?

[Matthieu Moy]

"Michael S. Tsirkin" <mst@redhat.com> 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/

Re: autopacking twice?

[Michael S. Tsirkin]

On Sun, Jun 22, 2014 at 05:22:32PM +0200, Matthieu Moy wrote:
> "Michael S. Tsirkin" <mst@redhat.com> 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/

Re: autopacking twice?

[Duy Nguyen]

On Sun, Jun 22, 2014 at 12:51 PM, Michael S. Tsirkin <mst@redhat.com> 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