Sam Vilain wrote: > Let me explain further. If in fast-import.c:new_object, if it were to > make a struct object (see object.h), and make sure it was put in > obj_hash (see object.c, particularly create_object()), then you might > find a whole load of plumbing would magically start working and be able > to work with the new objects that you are trying to load. Of course > there may be a couple of other functions which might need to change. > Primarily object.c:read_object, which needs to be able to check the > packfile being spooled by git fast-import. > > If you did this, then to implement this feature you could in principle > just call read_sha1_file() Oh, to implement the ‘cat’ feature, I was planning to call gfi_unpack_entry; the hard part is finding a spare moment to do that (if others have more spare moments, I would be happy to find that step unnecessary). What you describe sounds more useful as part of a longer-term plan. If fast-import and its caller live in the same process, then being able to use the usual object access APIs would be convenient indeed. In other words, it sounds like an incentive to libify fast-import. Well, everything in due time. Thanks for the comments, Jonathan -- 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