Hi, list!

I wrote about the related issue earlier:

http://lists-archives.org/git/731516-false-positives-from-git-diff-index-when-used-wit...

Now I've got a case when I can reproduce this problem each time I try to.

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

Anyway, I'm ready to debug this issue if someone will guide me.

Workflow:

<...change files in /path/dir1/...>
(cd /path && git add </path/dir1/>)
(cd /path && git commit -m <message1>)

... repeat change-add-commit several times for various directories
(can be the same directory or not) ...

<...generate file /path/dirN/foo...>
# Accidentally the file is generated the same as it was

(cd /path && git add </path/dirN/>)
(cd /path && git status) # Refresh index
(cd /path && git diff-index --exit-code --quiet HEAD -- /path/dirN) #
Incorrectly reports that there are some changes
(cd /path && git commit -m <messageN>) # fails, saying that there is
nothing to commit

If I insert sleep 10 between git status and git diff-index, the
problem goes away.

Any help?
Alexander.
--

[ message continues ]

Nobody is interested?

Is there a way I can get some help with this issue?

Thanks,
Alexander.

--

[ message continues ]

Your problem set appears that you have a rather gnarly corner case
issue, arising from your custom build processes. Although git really
is amazing, I believe you may well be pushing git to its technological
limits.

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

It also appears that your custom complicated build process is likely
protecting, or at least integral to, your high value corporate process
assets.

So _in this case_ you would be remiss to not find a suitable
consultant to provide professional and discreet assistance - perhaps
GitHub.com, as GitHub’s Tender provides both public and _private_
support issue posting, and customized and private training if you and/
or your colleagues require; you might contact GitHub direct (
https://github.com/contact ) as their Support page does not link
directly to support contract information; oh, and GitHub supports a
lot of community projects too: their support for our community ought
be supported.

<disclaimer> I am _not_ affiliated with GitHub, I do work full time
with a human rights association in Australia.

Good luck
...
--

[ message continues ]

Committing few megabytes of data several times per second is

Thank you for your opinion.

I view this particular situation as follows:

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

2. I can live happily with sleep(0.2) in my deployment code (while
this is not very satisfying, it is acceptable — certainly cheaper than
a paid consultant).

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.

4. The sole reason I'm pinging back on this bug report is that I'm
afraid to accidentally lose the data snapshot (or something in
environment) that makes the issue reproducible.

5. If no one is interested, well, that's opensource :-) No hard feelings.

Alexander.
--

[ message continues ]

Well, at least it is not what version control system is about; git is
designed towards manual and not automatic commits, and version control

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

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.


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)?

-- 
Jakub Narebski
Poland
ShadeHawk on #git
--

[ message continues ]

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


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

[ message continues ]