On Fri, Jan 29, 2010 at 11:16:31PM -0800, Junio C Hamano wrote: > As I said in my review during the earlier rounds, I do not know if it is > safe to use the flags and do the traversal inside this same process. You > may be clearing the flags to protect your traversal (one per branch) from > stepping on each other, but how would this affect the use of object flags > in existing parts of the "push" machinery? Is the reasoning that even if > push calls into traversal code and after it walked the commit ancestry for > its own purpose, your addition will clear the flags and existing code will > never look at object flags again, so this new code is free to use them and > all is Ok? As long as you made sure that nobody looks at object flags you > modified, then I am fine with that---I just don't know if that is what is > happening here, and that is why I am asking. > > I'd need help from the usual "transport" suspects for this patch. Well, I can say smart transports implemented by remote helpers are similar to ssh://&co (no surprise, they connect differently, but use the same underlying client code). Furthermore, actual remote helper stub code doesn't seem to play with revisions. And the actual remote helper parts seem to use clean memory image anyway (they exec). So that leaves the following: - git:// "layer 7" (git://, ssh://, file:// & co.[*]) - rsync:// (third-class anyway) Also, what about multiple-URL case? Don't know if there are problems, but it seems to be quite rarely tested... [*] OTOH, this is extremely heavily used code, so breakages here will usually be pretty visible. -Ilari -- 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