Jeff King <peff@xxxxxxxx> writes: > On Thu, Apr 21, 2016 at 03:20:39PM -0700, Junio C Hamano wrote: > >> * jk/push-client-deadlock-fix (2016-04-20) 5 commits >> - t5504: drop sigpipe=ok from push tests >> - fetch-pack: isolate sigpipe in demuxer thread >> - send-pack: isolate sigpipe in demuxer thread >> - run-command: teach async threads to ignore SIGPIPE >> - send-pack: close demux pipe before finishing async process >> >> "git push" from a corrupt repository that attempts to push a large >> number of refs deadlocked waiting for a rejection from the >> receiving end that will never come. >> >> Will merge to 'next'. > > Minor nit, but the deadlock is the other way around: the rejection > showed up and our demuxer is blocked writing to a reader who does not > care about it. > > Might be worth fixing since this text goes into the topic merge commit > (though I really hope nobody ever has to debug it enough ever again for > that distinction to matter :) ). Thanks. Something like this, perhaps? "git push" from a corrupt repository that attempts to push a large number of refs deadlocked; the thread to relay rejection notices for these ref updates blocked on writing them to the main thread, after the main thread at the receiving end notices that the push failed and decides not to read these notices and return a failure. >> * da/user-useconfigonly (2016-04-01) 2 commits >> - ident: give "please tell me" message upon useConfigOnly error >> - ident: check for useConfigOnly before auto-detection of name/email >> >> The "user.useConfigOnly" configuration variable makes it an error >> if users do not explicitly set user.name and user.email. However, >> its check was not done early enough and allowed another error to >> trigger, reporting that the default value we guessed from the >> system setting was unusable. This was a suboptimal end-user >> experience as we want the users to set user.name/user.email without >> relying on the auto-detection at all. >> >> Waiting for Acks. >> ($gmane/290340) > > I think you are waiting for the Ack from the original author on your > tweaks. But FWIW, what you have queued looks good to me. What often happens is that I start waiting, and then when necessary actions to move things forward is never taken, and there are many other topics that need my attention to move forward, I stop caring, especially when the topic is not something other people care about (if the original author does not care deeply enough, why should we?). Let me read it over again as it has been a while and then move it forward with your Reviewed-by's. >> * dk/gc-more-wo-pack (2016-01-13) 4 commits >> - gc: clean garbage .bitmap files from pack dir >> - t5304: ensure non-garbage files are not deleted >> - t5304: test .bitmap garbage files >> - prepare_packed_git(): find more garbage >> >> Follow-on to dk/gc-idx-wo-pack topic, to clean up stale >> .bitmap and .keep files. >> >> Waiting for a reroll. >> ($gmane/284368). > > This one's getting pretty stale, but as I recall was pretty close to > done. I'll try to give it a look in the next couple of days. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html