On Tue, Jan 4, 2011 at 14:08, Jakub Narebski <jnareb@gmail.com> wrote:
quoted text
> 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:

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

quoted text
>> 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!)

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

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

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

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

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html