Duy Nguyen <pclouds@xxxxxxxxx> writes: > I think this applies to general case as well, not just shallow. > Imagine I have a disconnected commit that points to the latest tree > (i.e. it contains most of latest changes). Because it's disconnected, > it'll be ignored by the server side. But if the servide side does > mark_tree_interesting on this commit, a bunch of blobs might be > excluded from sending. I think you meant mark_tree_UNinteresting. > ... So perhaps we could go over have_obj list > again, if it's not processed and is > > - a tree-ish, mark_tree_uninteresting > - a blob, just mark unintesting > > and this does regardless of shallow state or edges. As a general idea, I agree it may be worth trying out to see if your concern that the "have" list may be so big that this approach may be more costly than it is worth. If the recipient is known to have something, we do not have to send it. The things that we decide not to send are not necessarily what the recipient has, which introduces a twist you need to watch out for if we want to go that route. If the recipient is known to have something, a thin transfer can send a delta against it. You do not want to send the commits before the shallow boundary (i.e. the parents of the commits listed in .git/shallow) because the recipient does not want them, and that means you may have to use a different mark to record that fact. The recipient does not have them, we do not want to send them, and they cannot be used as a delta base for what we do send. Which is quite different from the ordinary "uninteresting" objects, those we decide not to send because the recipient has them. -- 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