Re: [PATCH/RFC 2/2] receive-pack: hint that the user can stop "git push" at auto gc time
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 4, 2014, 18:32 UTC
- Message-ID
- <xmqqd2j2afup.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <xmqqha8eag6c.fsf@gitster.dls.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
Show 25 quoted lines
> Nguyễn Thái Ngọc Duy <pclouds@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 <pclouds@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?