On Thu, Aug 28, 2014 at 04:14:01PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Thu, Aug 28, 2014 at 06:08:21PM -0400, Jeff King wrote:
> >
> >> Interesting. I couldn't convince Helgrind to catch such a case...
> >
> > Ugh. It helps if you actually helgrind the git binary, and not t
Jeff King writes:
> On Thu, Aug 28, 2014 at 06:08:21PM -0400, Jeff King wrote:
>
>> Interesting. I couldn't convince Helgrind to catch such a case...
>
> Ugh. It helps if you actually helgrind the git binary, and not the
> shell-script from bin-wrappers. I can easily replicate the problem now.
>
On Thu, Aug 28, 2014 at 06:15:18PM -0400, Jeff King wrote:
> As I implemented, I realized that even with the mutex, I really was just
> implementing compare_and_swap (and I wrote it that way to make it more
> obvious). So if we wanted to, it would be trivial to replace the
> "claim_delta" function
On Thu, Aug 28, 2014 at 06:08:21PM -0400, Jeff King wrote:
> Interesting. I couldn't convince Helgrind to catch such a case...
Ugh. It helps if you actually helgrind the git binary, and not the
shell-script from bin-wrappers. I can easily replicate the problem now.
The patch I just posted seems t
On Thu, Aug 28, 2014 at 06:08:21PM -0400, Jeff King wrote:
> So we need some kind of mutual exclusion so that only one thread
> proceeds with resolving the delta. The "real_type" check sort-of
> functions in that way (except of course it is not actually thread safe).
Here's a patch which implemen
On Mon, Aug 25, 2014 at 06:39:45PM +0200, René Scharfe wrote:
> Thanks, that looks good. But while preparing the patch I noticed that
> the added test sometimes fails. Helgrind pointed outet a race
> condition. It is not caused by the patch to turn the asserts into
> regular ifs, however -- her
On Sat, Aug 23, 2014 at 3:56 AM, Jeff King wrote:
> [+cc spearce, as I think this is a bug in code.google.com's sending
> side, and he can probably get the attention of the right folks]
...
> My guess is a bug on the sending side. We have seen duplicate pack
> objects before, but never (AFAIK) co
Am 23.08.2014 um 13:18 schrieb Jeff King:
> On Sat, Aug 23, 2014 at 07:04:59AM -0400, Jeff King wrote:
>
>> On Sat, Aug 23, 2014 at 06:56:40AM -0400, Jeff King wrote:
>>
>>> So I think your patch is doing the right thing.
>>
>> By the way, if you want to add a test to your patch, there is
>> infra
On Sat, Aug 23, 2014 at 07:04:59AM -0400, Jeff King wrote:
> On Sat, Aug 23, 2014 at 06:56:40AM -0400, Jeff King wrote:
>
> > So I think your patch is doing the right thing.
>
> By the way, if you want to add a test to your patch, there is
> infrastructure in t5308 to create packs with duplicate
On Sat, Aug 23, 2014 at 06:56:40AM -0400, Jeff King wrote:
> So I think your patch is doing the right thing.
By the way, if you want to add a test to your patch, there is
infrastructure in t5308 to create packs with duplicate objects. If I
understand the problem correctly, you could trigger this
[+cc spearce, as I think this is a bug in code.google.com's sending
side, and he can probably get the attention of the right folks]
On Sat, Aug 23, 2014 at 12:12:08PM +0200, René Scharfe wrote:
> Git 1.7.6 clones the repo without reporting an error or warning, but a
> check shows that a tree obj
Am 22.08.2014 um 21:41 schrieb Martin von Gagern:
> On 21.08.2014 13:35, Petr Stodulka wrote:
>> Hi guys,
>> I wanted post you patch here for this bug, but I can't find primary
>> source of this problem [0], because I don't understand some ideas in the
>> code.
>>
>> […]
>>
>> Any next ideas/hints
On 21.08.2014 13:35, Petr Stodulka wrote:
> Hi guys,
> I wanted post you patch here for this bug, but I can't find primary
> source of this problem [0], because I don't understand some ideas in the
> code.
>
> […]
>
> Any next ideas/hints or explanation of these functions? I began study
> source c
Bug is reprodusible since git version 1.8.3.1 (may earlier 1.8.xx, but
I don't test it) to actual upstream version.
This problem "doesn't exists" in version 1.7.xx - or more precisely is
not reproducible. "May" this is reproducible
since commit "7218a215" - in this commit was added assert in
Hi guys,
I wanted post you patch here for this bug, but I can't find primary
source of this problem [0], because I don't understand some ideas in the
code. So what I investigate:
Bug is reprodusible since git version 1.8.3.1 (may earlier 1.8.xx, but I
don't test it) to actual upstream version
15 matches
Mail list logo
