From: Junio C Hamano <hidden> Date: 2016-06-15 22:59:49
Junio C Hamano [off-list ref] writes:
Nguyễn Thái Ngọc Duy [off-list ref] writes:
quoted
Housekeeping jobs like auto gc generally should not get in the way.
Users who are pushing may not want to wait until auto gc is done on
the server. Give a hint for those users that it's safe now to break
"git push" and stop waiting.
Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
---
This bandage patch may be a good compromise between running auto gc
and not annoying users much.
If I'm not mistaken, when ^C on "git push" this way, gc will still be
running until it needs to print something out (which it should not
normally because of --quiet). The user won't see gc errors, but the
user generally can't do much anyway.
If you are over local transport, I would think you would kill the
both ends. Also, wouldn't killing "git push" before it is done
talking with the receive-pack stop it before it has a chance to
update the remote tracking refs to pretend as if it fetched from
there immediately after a push?
So, no. I do not think we should ever encourage "if this bothers
you, you can ^C it". Making it not to bother is fine, though.
Instead of adding a boolean --break-ok that is hidden, why not
adding an exposed boolean --daemonize, and let auto-gc run in the
background? With the recent "do not let more than one gc run at the
same time", that should give a lot more pleasant end user
experience, no?
Instead of adding a boolean --break-ok that is hidden, why not
adding an exposed boolean --daemonize, and let auto-gc run in the
background? With the recent "do not let more than one gc run at the
same time", that should give a lot more pleasant end user
experience, no?
That sounds quite useful to me. Duy, are you up for generating such a patch?
Thanks,
Chris
On Fri, Feb 7, 2014 at 7:36 PM, chris [off-list ref] wrote:
Junio C Hamano <gitster <at> pobox.com> writes:
quoted
Instead of adding a boolean --break-ok that is hidden, why not
adding an exposed boolean --daemonize, and let auto-gc run in the
background? With the recent "do not let more than one gc run at the
same time", that should give a lot more pleasant end user
experience, no?
That sounds quite useful to me. Duy, are you up for generating such a patch?
It would not be so hard for that patch. I'm still thinking whether it
should be done if auto-gc is started on the client side too (sometimes
it does, which is equally annoying)..
--
Duy
On Fri, Feb 7, 2014 at 7:36 PM, chris <jugg <at> hotmail.com> wrote:
quoted
Junio C Hamano <gitster <at> pobox.com> writes:
quoted
Instead of adding a boolean --break-ok that is hidden, why not
adding an exposed boolean --daemonize, and let auto-gc run in the
background? With the recent "do not let more than one gc run at the
same time", that should give a lot more pleasant end user
experience, no?
That sounds quite useful to me. Duy, are you up for generating such a
patch?
It would not be so hard for that patch. I'm still thinking whether it
should be done if auto-gc is started on the client side too (sometimes
it does, which is equally annoying)..
That could be nice, but I'd be less concerned about that, as the client has
the ability to disable gc for itself. Still pushing it into the background,
if considered acceptable behavior, seems reasonable. Perhaps two separate
patches?
Chris
@@ -1333,9 +1310,10 @@ int main(int argc, char **argv)if(inetd_mode||serve_mode)returnexecute();-if(detach)-daemonize();-else+if(detach){+if(daemonize())+die("--detach not supported on this platform");+}elsesanitize_stdfds();if(pid_file)
`gc --auto` takes time and can block the user temporarily (but not any
less annoyingly). Make it run in background on systems that support
it. The only thing lost with running in background is printouts. But
gc output is not really interesting. You can keep it in foreground by
changing gc.autodetach.
Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
---
Documentation/config.txt | 4 ++++
builtin/gc.c | 23 ++++++++++++++++++-----
t/t5400-send-pack.sh | 1 +
3 files changed, 23 insertions(+), 5 deletions(-)
@@ -1167,6 +1167,10 @@ gc.autopacklimit:: --auto` consolidates them into one larger pack. The default value is 50. Setting this to 0 disables it.+gc.autodetach::+ Make `git gc --auto` return immediately andrun in background+ if the system supports it. Default is true.+ gc.packrefs:: Running `git pack-refs` in a repository renders it unclonable by Git versions prior to 1.5.1.2 over dumb
@@ -301,11 +306,19 @@ int cmd_gc(int argc, const char **argv, const char *prefix)*/if(!need_to_gc())return0;-if(!quiet)-fprintf(stderr,-_("Auto packing the repository for optimum performance. You may also\n"-"run \"git gc\" manually. See "-"\"git help gc\" for more information.\n"));+if(!quiet){+if(detach_auto)+fprintf(stderr,_("Auto packing the repository in background for optimum performance.\n"));+else+fprintf(stderr,_("Auto packing the repository for optimum performance.\n"));+fprintf(stderr,_("See \"git help gc\" for manual housekeeping.\n"));+}+if(detach_auto)+/*+*failuretodaemonizeisok,we'llcontinue+*inforeground+*/+daemonize();}elseadd_repack_all_option();
@@ -164,6 +164,7 @@ test_expect_success 'receive-pack runs auto-gc in remote repo' '# Set the child to auto-pack if more than one pack existscdchild&&gitconfiggc.autopacklimit1&&+gitconfiggc.autodetachfalse&&gitbranchtest_auto_gc&&# And create a file that follows the temporary object naming# convention for the auto-gc to remove
From: Erik Faye-Lund <hidden> Date: 2016-06-15 22:59:52
On Sat, Feb 8, 2014 at 8:08 AM, Nguyễn Thái Ngọc Duy [off-list ref] wrote:
quoted hunk
`gc --auto` takes time and can block the user temporarily (but not any
less annoyingly). Make it run in background on systems that support
it. The only thing lost with running in background is printouts. But
gc output is not really interesting. You can keep it in foreground by
changing gc.autodetach.
Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
---
Documentation/config.txt | 4 ++++
builtin/gc.c | 23 ++++++++++++++++++-----
t/t5400-send-pack.sh | 1 +
3 files changed, 23 insertions(+), 5 deletions(-)
@@ -1167,6 +1167,10 @@ gc.autopacklimit:: --auto` consolidates them into one larger pack. The default value is 50. Setting this to 0 disables it.+gc.autodetach::+ Make `git gc --auto` return immediately andrun in background+ if the system supports it. Default is true.+ gc.packrefs:: Running `git pack-refs` in a repository renders it unclonable by Git versions prior to 1.5.1.2 over dumb
@@ -301,11 +306,19 @@ int cmd_gc(int argc, const char **argv, const char *prefix)*/if(!need_to_gc())return0;-if(!quiet)-fprintf(stderr,-_("Auto packing the repository for optimum performance. You may also\n"-"run \"git gc\" manually. See "-"\"git help gc\" for more information.\n"));+if(!quiet){+if(detach_auto)+fprintf(stderr,_("Auto packing the repository in background for optimum performance.\n"));+else+fprintf(stderr,_("Auto packing the repository for optimum performance.\n"));+fprintf(stderr,_("See \"git help gc\" for manual housekeeping.\n"));+}+if(detach_auto)+/*+*failuretodaemonizeisok,we'llcontinue+*inforeground+*/+daemonize();
While I agree that it should be OK, shouldn't we warn the user?
On Mon, Feb 10, 2014 at 6:03 PM, Erik Faye-Lund [off-list ref] wrote:
quoted
`gc --auto` takes time and can block the user temporarily (but not any
- if (!quiet)
- fprintf(stderr,
- _("Auto packing the repository for optimum performance. You may also\n"
- "run \"git gc\" manually. See "
- "\"git help gc\" for more information.\n"));
+ if (!quiet) {
+ if (detach_auto)
+ fprintf(stderr, _("Auto packing the repository in background for optimum performance.\n"));
+ else
+ fprintf(stderr, _("Auto packing the repository for optimum performance.\n"));
+ fprintf(stderr, _("See \"git help gc\" for manual housekeeping.\n"));
+ }
+ if (detach_auto)
+ /*
+ * failure to daemonize is ok, we'll continue
+ * in foreground
+ */
+ daemonize();
While I agree that it should be OK, shouldn't we warn the user?
If --quiet is set, we should not be printing anyway. If not, I thinkg
we could only print "auto packing in background.." when we actually
can do that, else just print the old message. It means an #ifdef
NO_POSIX_GOODIES here again though..
--
Duy
From: Erik Faye-Lund <hidden> Date: 2016-06-15 22:59:52
On Mon, Feb 10, 2014 at 2:17 PM, Duy Nguyen [off-list ref] wrote:
On Mon, Feb 10, 2014 at 6:03 PM, Erik Faye-Lund [off-list ref] wrote:
quoted
quoted
`gc --auto` takes time and can block the user temporarily (but not any
- if (!quiet)
- fprintf(stderr,
- _("Auto packing the repository for optimum performance. You may also\n"
- "run \"git gc\" manually. See "
- "\"git help gc\" for more information.\n"));
+ if (!quiet) {
+ if (detach_auto)
+ fprintf(stderr, _("Auto packing the repository in background for optimum performance.\n"));
+ else
+ fprintf(stderr, _("Auto packing the repository for optimum performance.\n"));
+ fprintf(stderr, _("See \"git help gc\" for manual housekeeping.\n"));
+ }
+ if (detach_auto)
+ /*
+ * failure to daemonize is ok, we'll continue
+ * in foreground
+ */
+ daemonize();
While I agree that it should be OK, shouldn't we warn the user?
If --quiet is set, we should not be printing anyway. If not, I thinkg
we could only print "auto packing in background.." when we actually
can do that, else just print the old message. It means an #ifdef
NO_POSIX_GOODIES here again though..
Yuck, it's probably better to simply silently drop the detaching, I guess.