Jeff King venit, vidit, dixit 07.02.2013 10:55: > On Thu, Feb 07, 2013 at 10:47:55AM +0100, Michael J Gruber wrote: > >>> I'd be OK if we had an exterior object_context that could be handled >>> in the same way. But how do we tell setup_revisions that we are >>> interested in seeing the object_context from each parsed item, where >>> does the allocation come from (is it malloc'd by setup_revisions?), and >>> who is responsible for freeing it when we pop pending objects in >>> get_revisions and similar? >> >> Do we really need all of tree, path and mode in object_context (I mean >> not just here, but other users), or only the path? I'd try and resurrect >> the virtual path name objects then, they would be just like "item" >> storage-wise. > > We need at least mode, since that is how the mode parameter of > object_array_entry gets set. I do not know off-hand who uses "tree". I > suspect the intent was to do .gitattributes lookups inside that tree, > but I do not think we actually do in-tree lookups currently. > >>> I don't think it's as clear cut. >>> >>> I wonder, though...what we really care about here is just the pathname. >>> But if it is a pending object that comes from a blob revision argument, >>> won't it always be of the form "treeish:path"? Could we not even resolve >>> the sha1 again, but instead just parse out the ":path" bit? >> >> Do we have that, and in what form (e.g. magic expanded etc.)? > > Ah, I should have mentioned that. :) We should have the original rev > name in the object_array_entry's name field, shouldn't we? It's just a > matter of re-parsing it. > >> Another thing I noted is that our path mangling at least for grep has >> some issues: >> >> (cd t && git grep GET_SHA1_QUIETLY HEAD:../cache.h) >> ../HEAD:../cache.h:#define GET_SHA1_QUIETLY 01 > > Yuck. And even more yuck: (cd t && git grep --full-name GET_SHA1_QUIETLY HEAD:../cache.h) HEAD:../cache.h:#define GET_SHA1_QUIETLY 01 Someone does not expect a "rev:" to be in there, it seems ;) Michael -- 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