Re: [PATCH/RFC 2/2] receive-pack: hint that the user can stop
Junio C Hamano gitster at pobox.com writes: 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 -- 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
On Fri, Feb 7, 2014 at 7:36 PM, chris j...@hotmail.com wrote: Junio C Hamano gitster at pobox.com writes: 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 -- 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
Duy Nguyen pclouds at gmail.com writes: On Fri, Feb 7, 2014 at 7:36 PM, chris jugg at hotmail.com wrote: Junio C Hamano gitster at pobox.com writes: 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 -- 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 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. -- 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
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
