Re: False positives in git diff-index

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 4, 2011 at 14:08, Jakub Narebski <jnareb@xxxxxxxxx> wrote:
> Alexander Gladysh <agladysh@xxxxxxxxx> writes:
>> On Tue, Jan 4, 2011 at 14:47, Zenaan Harkness <zen@xxxxxxxxxxxx> wrote:
>> > On Tue, Jan 4, 2011 at 20:45, Alexander Gladysh <agladysh@xxxxxxxxx> wrote:

>> > So your problem could be quite hard to debug, whilst being distinctly
>> > difficult to ascertain the root causes.

>> 1. I found a reproducible case for a hard to catch bug in Git. (This
>> is a bug in Git, not in my build process.) This bug in its
>> intermittent form annoyed me for quite some time â several months at
>> least â and is likely to annoy other users. (I'm not *that* unique!)

> But it is reproductible to you: from what I understand you didn't find
> some minimal example to reproduce this issue without need for access
> your proprietary build process.

> AG> Unfortunately I can not share it or create a minimal example ? the
> AG> case is triggered by a custom complicated automated build process on a
> AG> private repository.

Yes, that is true. Still, much, much better than intermittent.

>> 3. I'm willing to help Git developers with catching this bug for
>> mutual benefit â I will get rid of annoying issue and make my
>> deployment code more robust. Git will, well, be a bit more robust as
>> well.

> To debug it, if you cannot do it yourself, you would have to find git
> developer who is both knowledgeable about fairly deep part of git
> code, and can work with remote debugging with you at remote.

I understand that. But is the second part of requirement is such a
large problem?

Anyway, as I said, if no one will step up, no problem.

> P.S. Somewhere in the depths of git maling list archive (it didn't
> unfortunately made it to "Interfaces, Frontends and tools" page on git
> wiki) there is tool/script for anonymizing git repository, to allow
> debugging of bugs which occurs in some repositories that cannot be
> made public. ÂPerhaps something similar could be done for your build
> process (you need to reproduce only stat + git part)?

I remember, somebody advised me to use this tool, when I reported some
bug some time (maybe a year) ago.

But, I'm afraid, I do not know how to separate my deployment tool
logic (which reproduces the bug) from the repository data. If I did
know, I'd come up with a minimal example already. Nothing trivial
"along the lines", that I tried so far, does reproduce it.

Alexander.
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]