Junio C Hamano <gits...@pobox.com> writes: > Nguyễn Thái Ngọc Duy <pclo...@gmail.com> 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 <pclo...@gmail.com> >> --- >> 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
