Re: [BUG] resolved deltas

From: Martin von Gagern <martin.vgagern@gmx.net>
Date: Aug 22, 2014, 19:41 UTC
Message-ID: <53F79CE3.60803@gmx.net>
In-Reply-To: <53F5D98F.4040700@redhat.com>

On 21.08.2014 13:35, Petr Stodulka wrote:

Show 15 quoted lines

> 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 mechanisms of the git this week, so don't beat me yet
> please :-)
> 
> Regards,
> Petr
> 
> [0] https://bugzilla.redhat.com/show_bug.cgi?id=1099919

Some pointers to related reports and investigations:

https://groups.google.com/forum/#!topic/mapsforge-dev/IF6mgmwvZmY https://groups.google.com/forum/#!topic/mapsforge-dev/f2KvFALlkvo https://code.google.com/p/support/issues/detail?id=31571 https://groups.google.com/forum/#!topic/mapsforge-dev/nomzr5dkkqc http://thread.gmane.org/gmane.comp.version-control.git/254626

The last is my own bug report to this mailing list here, which unfortunately received no reaction yet. In that report, I can confirm that the commit introducing the assertion is the same commit which causes things to fail: https://github.com/git/git/commit/7218a215efc7ae46f7ca8d82442f354e

In this https://code.google.com/p/mapsforge/ repository, resolve_delta gets called twice for some delta. The first time, type and real_type are identical, but by the second pass in find_unresolved_deltas the real type will have chaned to OBJ_TREE. This caused the old code to simply scip the object, but the new code aborts instead.

So far my understanding. I'm not sure whether this kind of duplicate resolution is something normal or indicates some breakage in the repository in question. But aborting seems a bad solution in either case.

Greetings,
 Martin von Gagern