On Thu, May 2, 2013 at 6:35 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > >> --not-so-strict only checks if all links from objects in the pack >> point to real objects (either in current repo, or from the pack >> itself). It's like check_everything_connected() except that: >> >> - it does not follow DAG in order >> - it can detect incomplete object islands > > Could you clarify what this second point means? > > "rev-list --objects --all --not $this $that" does not detect > "islands" but checking with the updated index-pack does? Object islands (in the new pack) by definition are not connected to the main DAG and so invisible to/unreachable from rev-list. index-pack examines all objects in the pack and checks links of each object. With this approach, islands are no different than reachable objects. >> - it seems to be faster than "rev-list --objects --all" > > More important is that it makes sure that it is safe to update our > refs to the new value, just like the check this attempts to replace. > If that is not the case, the speed does not matter. > > I am guessing that the code assumes that we are updating our refs to > objects that are in the pack that we are looking at, and I can see > how the new check in sha1_object() may detect an object that points > at another object that is missing. But that assumption (which I > think is correct) is probably the most important thing to say in the > log message. Yes, we need to make sure the new value of our refs are existing objects. But it does not need to be in the new pack. After index-pack is run, we're guaranteed that all objects in repo are connected and any of them could be new ref. This is also why I add has_sha1_file() in clone.c. I forget if I have checked for similar call in fetch.c and receive-pack.c. Will look again (and update log message) >> +--not-so-strict:: > > Perhaps "--check-connectivity" is a better name than this? Definitely. -- Duy -- 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