On 25/01/08 02:43PM, Junio C Hamano wrote: > Justin Tobler <jltobler@xxxxxxxxx> writes: > > >> As I suspect that we would want to leave the door open for us to > >> extend this later, I would perhaps suggest an output format format > >> like: > >> > >> ?<object name> [<token>=<value>]... > > > > I think this is a great idea. To select which attributes get printed > > with the missing object we could add an option. Something like: > > > > $ git rev-list --objects --missing=print \ > > --missing-attr=path --missing-attr=type > > My knee-jerk reaction is that this is over-engineered; wouldn't it > be possible for us to simply dump everything we know about the > object, and let the receiving end pick and choose? I think that should also be fine and much simpler. We may not want to effect the existing output of `--missing=print` though, so we could have a simple boolean option like `--missing-attr` or just add a new missing action type like `--missing=print-attr`. When enabled it would just print all the identified attributes. If we don't care though, we could keep it very simple and just add all the information whenever `--missing=print` is set. > > I like the idea of also adding a path attribute, but this raises a > > couple of questions. The way `--missing=print` currently works is that > > it prints the unique set of missing object IDs. A missing object could > > possibly be referenced by multiple trees and thus have multiple valid > > paths. > > That is not an issue at all, I think. "rev-list --objects" that > shows objects that are not missing already has the same issue, and > the solution is "show the path when the object gets shown for the > first time". Even when the same object is encountered during the > history-and-then-tree walk later, that object is simply not listed. > > The code path that collects "I thought this blob should exist > because a tree wants to see it at this path, but the repository is > corrupt and I cannot see it there" into the missing object table > with attributes should do the same. If the table does not yet have > the object, record the attributes (like "expected type", "path at > which the object was found") when inserting the object into the > table for the first time. If you have a missing object and the > table already has it recorded there, don't do anything extra. Good to know! That makes things a bit simpler. I'll follow this approach and only add the missing object to the table if an object with the same OID is not already recorded. -Justin
