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 -- here's
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 implements
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
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 with
Jeff King p...@peff.net 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
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
infrastructure in
On Sat, Aug 23, 2014 at 3:56 AM, Jeff King p...@peff.net 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
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 or explanation
[+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
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
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 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 code and
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
snip
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
14 matches
Mail list logo
