Sverre Rabbelier <srabbelier@xxxxxxxxx> writes: > Ok, knowing that, I am somewhat more inclined to have a look at this. > I'm still not sure that I know how to implement the design you > described though. I mean, I understand the general concept, but I have > no idea in what places it would need to hook in to make it work (ditto > on how to fix the diff bug). It is entirely possible, as Dscho hinted in his response, that your "flag" word may be sufficient to encode "where did this object (whether it is marked as uninteresting or interesting) come from? what did the user want to do with it?" information for all practical purposes, even though I doubt one bit would be sufficient. So how about ignoring "diff A...B" vs "diff ^C A B" in the meantime and see if your change to revision.c is applicable to the same issue in "git bundle" as a starter? I would imagine that "diff A...B" vs "diff ^C A B" case would be solved by the former (^C is the common ancestor between A and B) add a flag COMMON_ANCESTOR to pending object array entry that holds ^C, SYMMETRIC_LEFT to the one with A and SYMMETRIC_RIGHT to the one with B, while the latter would stuff one SINGLE_NEGATIVE (^C), and two SINGLE_POSITIVE (A and B), and the caller would tell between the two, or something like that. And "bundle master^0..master" (and similarly your export stream) would note the RHS of the dot operator with SYMMETRIC_RIGHT so that "master", even though the commit object gets marked as uninteresting at the end, can be recovered to be of interest to the end user. I am not suggesting the exact flag word names above, but just trying to enumerate how many kinds would be needed). Your single-bit in the patch would be SYMMETRIC_RIGHT in the above ugly notation, but you can call it REF_INTERESTING or whatever. -- 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