git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: bug? git push triggers auto pack when gc.auto = 0

From
Cchris <jugg@hotmail.com>
Date
Feb 4, 2014, 08:16 UTC
Message-ID
<loom.20140204T090417-126@post.gmane.org>
In-Reply-To
<CACsJy8B0WKfxSYBSgRZQYz6_h+S9pGd03A=rrWM0_twRdKvyZw@mail.gmail.com>
Duy Nguyen <pclouds <at> gmail.com> writes:
Show 17 quoted lines
> On Tue, Feb 4, 2014 at 12:13 PM, chris <jugg <at> hotmail.com> wrote:
> > 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.
> >
> > An obvious fix is to disable gc on the server and implement a cron job for
> > the house keeping task.  However, as often the case one does not have
> > control over the server, so it is unfortunate that git has this server side
> > house keeping as a blocking operation to a client action.
> 
> I agree it should not block the client. I think you can Ctrl-C "git
> push" at this point without losing anything (data has already been
> pushed at this point) but that's not a good advice to general cases.
> Maybe we can do something at the server side to not block the client..

I'd like to avoid a Ctrl-C approach, but if an indication existed that assured me the push part of the operation had completed successfully, then that would be sufficient for when I'm impatient.

> Another thing we could do is put "remote: " in front of these strings,
> even in ssh case. They seem to confuse you (and me too) that things
> happened locally.

Yes, I would like to see more explicit clarity in what messages are coming from the server. That has always been a source of uncertainty for me with any remote git command output.

Thanks for the patches and attention to this issue, I appreciate it.
Chris
Previous: Junio C HamanoNext: David Kastrup
Message 25 of 30 in “bug? git push triggers auto pack when gc.auto = 0”
  1. chrisFeb 4, 2014
  2. Duy NguyenFeb 4, 2014
  3. chrisFeb 4, 2014
  4. Duy NguyenFeb 4, 2014
  5. 1/2 receive-pack: update $GIT_DIR/info before auto garbage collectionNguyễn Thái Ngọc Duy, Feb 4, 2014
  6. 2/2 receive-pack: hint that the user can stop "git push" at auto gc timeNguyễn Thái Ngọc Duy, Feb 4, 2014
  7. Junio C HamanoFeb 4, 2014
  8. Junio C HamanoFeb 4, 2014
  9. chrisFeb 7, 2014
  10. Duy NguyenFeb 7, 2014
  11. chrisFeb 7, 2014
  12. 1/2 daemon: move daemonize() to libgit.aNguyễn Thái Ngọc Duy, Feb 8, 2014
  13. 2/2 gc: config option for running --auto in backgroundNguyễn Thái Ngọc Duy, Feb 8, 2014
  14. Erik Faye-LundFeb 10, 2014
  15. Duy NguyenFeb 10, 2014
  16. Erik Faye-LundFeb 10, 2014
  17. Junio C HamanoFeb 10, 2014
  18. Junio C HamanoFeb 10, 2014
  19. Duy NguyenFeb 12, 2014
  20. Junio C HamanoFeb 12, 2014
  21. Erik Faye-LundFeb 10, 2014
  22. Junio C HamanoFeb 10, 2014
  23. Duy NguyenFeb 10, 2014
  24. Junio C HamanoFeb 11, 2014
  25. chrisFeb 4, 2014
  26. David KastrupFeb 4, 2014
  27. chrisFeb 4, 2014
  28. David KastrupFeb 4, 2014
  29. chrisFeb 4, 2014
  30. David KastrupFeb 4, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.