Re: False positives in git diff-index

From: Alexander Gladysh <agladysh@gmail.com>
Date: Jan 4, 2011, 14:46 UTC
Message-ID: <AANLkTikD5znEPTqR-UeLsusV6sj80vO0dOPuK9QDN6LW@mail.gmail.com>
In-Reply-To: <m339p8dap4.fsf@localhost.localdomain>

On Tue, Jan 4, 2011 at 14:08, Jakub Narebski <jnareb@gmail.com> wrote:

> Alexander Gladysh <agladysh@gmail.com> writes:
>> On Tue, Jan 4, 2011 at 14:47, Zenaan Harkness <zen@freedbms.net> wrote:
>> > On Tue, Jan 4, 2011 at 20:45, Alexander Gladysh <agladysh@gmail.com> 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.

Show 6 quoted lines

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