From: Junio C Hamano <gitster@pobox•com>
To: Jeff King <peff@peff•net>
Cc: git@vger•kernel.org
Subject: Re: What's cooking in git.git (Apr 2016, #06; Thu, 21)
Date: Fri, 22 Apr 2016 10:22:42 -0700 [thread overview]
Message-ID: <xmqqa8klr21p.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20160422044258.GA31619@sigill.intra.peff.net> (Jeff King's message of "Fri, 22 Apr 2016 00:42:59 -0400")
Jeff King <peff@peff•net> 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.
next prev parent reply other threads:[~2016-04-22 17:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-21 22:20 What's cooking in git.git (Apr 2016, #06; Thu, 21) Junio C Hamano
2016-04-21 22:32 ` Stefan Beller
2016-04-21 22:48 ` Pranit Bauva
2016-04-22 17:23 ` Junio C Hamano
2016-04-22 22:12 ` Junio C Hamano
2016-04-23 18:42 ` Pranit Bauva
2016-04-21 22:51 ` Santiago Torres
2016-04-21 23:20 ` Junio C Hamano
2016-04-22 4:42 ` Jeff King
2016-04-22 17:22 ` Junio C Hamano [this message]
2016-04-22 18:38 ` Jeff King
2016-04-22 5:01 ` Torsten Bögershausen
2016-04-22 17:23 ` Junio C Hamano
2016-04-22 14:04 ` Johannes Schindelin
2016-04-22 17:24 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqa8klr21p.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=peff@peff$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox