Re: [PATCH/RFC 2/2] receive-pack: hint that the user can stop "git push" at auto gc time
Junio C Hamano writes: > Nguyễn Thái Ngọc Duy writes: > >> 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 >> --- >> 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [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 writes: > 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 > --- > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 2/2] receive-pack: hint that the user can stop "git push" at auto gc time
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
---
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.
builtin/gc.c | 9 -
builtin/receive-pack.c | 2 +-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/builtin/gc.c b/builtin/gc.c
index c19545d..592271a 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -253,6 +253,7 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
int auto_gc = 0;
int quiet = 0;
int force = 0;
+ int break_ok = 0;
const char *name;
pid_t pid;
@@ -263,6 +264,8 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
PARSE_OPT_OPTARG, NULL, (intptr_t)prune_expire },
OPT_BOOL(0, "aggressive", &aggressive, N_("be more thorough
(increased runtime)")),
OPT_BOOL(0, "auto", &auto_gc, N_("enable auto-gc mode")),
+ OPT_HIDDEN_BOOL(0, "break-ok", &break_ok,
+ "hint that it is ok to stop the program"),
OPT_BOOL(0, "force", &force, N_("force running gc even if there
may be another gc running")),
OPT_END()
};
@@ -301,7 +304,11 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
*/
if (!need_to_gc())
return 0;
- if (!quiet)
+ if (break_ok)
+ fprintf(stderr,
+ _("Auto packing the repository for optimum
performance.\n"
+ "It is safe to stop the program with
Ctrl-C.\n"));
+ else if (!quiet)
fprintf(stderr,
_("Auto packing the repository for
optimum performance. You may also\n"
"run \"git gc\" manually. See "
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 82e2f76..68d16e0 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -1212,7 +1212,7 @@ int cmd_receive_pack(int argc, const char **argv, const
char *prefix)
update_server_info(0);
if (auto_gc) {
const char *argv_gc_auto[] = {
- "gc", "--auto", "--quiet", NULL,
+ "gc", "--auto", "--quiet", "--break-ok", NULL,
};
int opt = RUN_GIT_CMD | RUN_COMMAND_STDOUT_TO_STDERR;
run_command_v_opt(argv_gc_auto, opt);
--
1.8.5.2.240.g8478abd
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
