From: chris <jugg@hotmail•com>
To: git@vger•kernel.org
Subject: Re: bug? git push triggers auto pack when gc.auto = 0
Date: Tue, 4 Feb 2014 08:59:45 +0000 (UTC) [thread overview]
Message-ID: <loom.20140204T094437-148@post.gmane.org> (raw)
In-Reply-To: 87r47jxp6k.fsf@fencepost.gnu.org
David Kastrup <dak <at> gnu.org> writes:
> chris <jugg <at> hotmail.com> writes:
> > Duy Nguyen <pclouds <at> gmail.com> writes:
> >> On Tue, Feb 4, 2014 at 9:20 AM, chris <jugg <at> hotmail.com> wrote:
> >> > $ git push origin next
> >> > Counting objects: 56, done.
> >> > Delta compression using up to 4 threads.
> >> > Compressing objects: 100% (9/9), done.
> >> > Writing objects: 100% (9/9), 895 bytes | 0 bytes/s, done.
> >> > Total 9 (delta 8), reused 0 (delta 0)
> >> > Auto packing the repository for optimum performance.
>
> > However, I question why I should even care about this message? I'm going to
> > assume that simply it is a lengthy synchronous operation that someone felt
> > deserved some verbosity to why the client push action is taking longer than
> > it should. Yet that makes me question why I'm being penalized for this
> > server side operation. My client time should not be consumed for server
> > side house keeping.
>
> Your "client time" is not consumed: this is not a busy wait. Git server
> processes are synchronous: they are initiated and completed under the
> control of a client. That means that if you run a batch script
> executing a number of commands in a client, it will not saturate the
> server with half-finished processes and/or will refuse to honor requests
> because the repository is locked.
I'm slightly confused by your response. You say "client time" is not
consumed, but then go on to say that git server processes are synchronous to
avoid build up from batched client requests. I expect you took "client
time" to have some specific technical meaning, while I simply meant that the
client command did not return until the server completed its own house keeping.
But I do think we are on the same page otherwise in that the client command
is blocked until the server process completes.
That said I would naively assume that a server side house keeping operation
that does not get invoked with every client request be a nice candidate for
asynchronous handling without any need to tell the client about it.
Regards,
Chris
next prev parent reply other threads:[~2014-02-04 9:00 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-04 2:20 bug? git push triggers auto pack when gc.auto = 0 chris
2014-02-04 2:41 ` Duy Nguyen
2014-02-04 5:13 ` chris
2014-02-04 6:02 ` Duy Nguyen
2014-02-04 6:52 ` [PATCH 1/2] receive-pack: update $GIT_DIR/info before auto garbage collection Nguyễn Thái Ngọc Duy
2014-02-04 6:52 ` [PATCH/RFC 2/2] receive-pack: hint that the user can stop "git push" at auto gc time Nguyễn Thái Ngọc Duy
2014-02-04 18:25 ` Junio C Hamano
2014-02-04 18:32 ` Junio C Hamano
2014-02-07 12:36 ` [PATCH/RFC 2/2] receive-pack: hint that the user can stop chris
2014-02-07 13:05 ` Duy Nguyen
2014-02-07 16:47 ` chris
2014-02-08 7:08 ` [PATCH v2 1/2] daemon: move daemonize() to libgit.a Nguyễn Thái Ngọc Duy
2014-02-08 7:08 ` [PATCH v2 2/2] gc: config option for running --auto in background Nguyễn Thái Ngọc Duy
2014-02-10 11:03 ` Erik Faye-Lund
2014-02-10 13:17 ` Duy Nguyen
2014-02-10 13:33 ` Erik Faye-Lund
2014-02-10 18:43 ` Junio C Hamano
2014-02-10 19:11 ` Junio C Hamano
2014-02-12 1:53 ` Duy Nguyen
2014-02-12 17:36 ` Junio C Hamano
2014-02-10 11:04 ` [PATCH v2 1/2] daemon: move daemonize() to libgit.a Erik Faye-Lund
2014-02-10 18:46 ` Junio C Hamano
2014-02-10 23:25 ` Duy Nguyen
2014-02-11 18:08 ` Junio C Hamano
2014-02-04 8:16 ` bug? git push triggers auto pack when gc.auto = 0 chris
2014-02-04 8:22 ` David Kastrup
2014-02-04 8:59 ` chris [this message]
2014-02-04 9:31 ` David Kastrup
2014-02-04 10:35 ` chris
2014-02-04 11:11 ` David Kastrup
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=loom.20140204T094437-148@post.gmane.org \
--to=jugg@hotmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox