Hi Peff,
On Fri, 10 Aug 2018, Jeff King wrote:
> On Fri, Aug 10, 2018 at 06:43:07PM +0200, Johannes Schindelin wrote:
>
> > So unless you are willing to ignore, to willfully keep this breakage,
> > I would suggest not to introduce the ugliness of an overridden
> > upload-pack for the sole
On Fri, Aug 10, 2018 at 11:34:59AM -0700, Junio C Hamano wrote:
> Johannes Sixt writes:
>
> > As this buglet looks like a recurring theme, and a proper fix is
> > preferable over repeated work-arounds. To me it looks like we need
> > some sort of locking on Windows. Unless your friends at
Jeff King writes:
> I have tried to help with the actual problem, by identifying the root
> cause (that the trace code's strategy is not fundamentally broken, but
> that it relies on O_APPEND whose guarantees are obviously not portable
> to Windows) and exploring possible solutions there
Johannes Sixt writes:
> As this buglet looks like a recurring theme, and a proper fix is
> preferable over repeated work-arounds. To me it looks like we need
> some sort of locking on Windows. Unless your friends at Microsoft have
> an ace in their sleeves that lets us have atomic O_APPEND the
On Fri, Aug 10, 2018 at 06:43:07PM +0200, Johannes Schindelin wrote:
> > > Correct. But I am more worried about the "mixed/overwriting"
> > > breakage, if there is one; it means we may need to be prepared for
> > > systems that lack O_APPEND that works correctly. I initially just
> > > assumed
Am 10.08.2018 um 18:51 schrieb Jeff Hostetler:
On 8/10/2018 12:15 PM, Johannes Sixt wrote:
Am 09.08.2018 um 19:35 schrieb Johannes Schindelin via GitGitGadget:
I reported a couple of times that t5552 is not passing reliably. It
has now
reached next, and will no doubt infect master soon.
On 8/10/2018 12:51 PM, Jeff Hostetler wrote:
On 8/10/2018 12:15 PM, Johannes Sixt wrote:
Am 09.08.2018 um 19:35 schrieb Johannes Schindelin via GitGitGadget:
I reported a couple of times that t5552 is not passing reliably. It
has now
reached next, and will no doubt infect master soon.
On 8/10/2018 12:15 PM, Johannes Sixt wrote:
Am 09.08.2018 um 19:35 schrieb Johannes Schindelin via GitGitGadget:
I reported a couple of times that t5552 is not passing reliably. It
has now
reached next, and will no doubt infect master soon.
Turns out that it is not a Windows-specific
Hi,
On Fri, 10 Aug 2018, Jeff King wrote:
> On Thu, Aug 09, 2018 at 01:49:52PM -0700, Junio C Hamano wrote:
>
> > Jeff King writes:
> >
> > > Are you sure that it's not well-defined? We open the path with O_APPEND,
> > > which means every write() will be atomically positioned at the end of
>
Am 09.08.2018 um 19:35 schrieb Johannes Schindelin via GitGitGadget:
I reported a couple of times that t5552 is not passing reliably. It has now
reached next, and will no doubt infect master soon.
Turns out that it is not a Windows-specific issue, even if it occurs a lot
more often on Windows
Jeff King writes:
> Here it is as a patch on top of jt/fetch-negotiator-skipping, which lets
> us pursue any fix for interleaved trace output on Windows without the
> pressure of an impending flaky test.
>
> My gut says that looking into making O_APPEND work there is going to be
> the nicest
Jeff King writes:
> Here it is as a patch on top of jt/fetch-negotiator-skipping, which lets
> us pursue any fix for interleaved trace output on Windows without the
> pressure of an impending flaky test.
>
> My gut says that looking into making O_APPEND work there is going to be
> the nicest
On Thu, Aug 09, 2018 at 01:49:52PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Are you sure that it's not well-defined? We open the path with O_APPEND,
> > which means every write() will be atomically positioned at the end of
> > file. So we would never lose or overwrite data.
> >
>
On Thu, Aug 09, 2018 at 02:08:56PM -0700, Junio C Hamano wrote:
> > Correct. But I am more worried about the "mixed/overwriting"
> > breakage, if there is one; it means we may need to be prepared for
> > systems that lack O_APPEND that works correctly. I initially just
> > assumed that it was
Junio C Hamano writes:
> Jeff King writes:
>
>> Are you sure that it's not well-defined? We open the path with O_APPEND,
>> which means every write() will be atomically positioned at the end of
>> file. So we would never lose or overwrite data.
>>
>> We do our own buffering in a strbuf, writing
Jeff King writes:
> Are you sure that it's not well-defined? We open the path with O_APPEND,
> which means every write() will be atomically positioned at the end of
> file. So we would never lose or overwrite data.
>
> We do our own buffering in a strbuf, writing the result out in a single
>
On Thu, Aug 09, 2018 at 10:35:24AM -0700, Johannes Schindelin via GitGitGadget
wrote:
> The culprit is that two processes try simultaneously to write to the same
> file specified via GIT_TRACE_PACKET, and it is not well defined how that
> should work, even on Linux.
Are you sure that it's not
I reported a couple of times that t5552 is not passing reliably. It has now
reached next, and will no doubt infect master soon.
Turns out that it is not a Windows-specific issue, even if it occurs a lot
more often on Windows than elsewhere.
The culprit is that two processes try simultaneously
18 matches
Mail list logo
