Jakub Narebski <jnareb@xxxxxxxxx> writes: > Couldn't it be solved by enhancing initial handshake to send from puller > (object receivier) to pullee (object sender) the contents of graft file, or > better the contents of cauterizing graft file - without splitting graft > file we better have an option to send graft file or not, when graft file is > used to join historical repository line of development not to cauterize > history. > > Then the sender would use sent cauterizing history graft file for > calculating which objects to sedn _only_, "in memory" cauterizing it's own > history. > > Now I guess you would tell me why this very simple idea is stupid... It is not stupid at all; what you said is actually on a correct track. You indeed just reinvented a half of what I've outlined earlier for implementing shallow clone (the other half you missed is that the graft exchange needs to happen both ways, limiting the commit ancestry graph the both ends walk to the intersection of the fake view of the ancestry graph both ends have, but that is a minor detail). The problem is that what Linus described as "fundamentally hard" is not the initial "shallow clone" stage, but lies elsewhere. Namely, what to do after you create such a shallow clone and when you want to unplug an earlier cauterization points. In order to unplug a cauterization point (a commit we faked to be parentless earlier, whose parents and associated objects we ought to have but we do not because we made a shallow clone), the downloader needs to re-fetch that commit while temporarily pretending that it does not have any objects that are newer, perhaps defining another earlier point as a new cauterization point at the same time. Git format allows for that, and the protocol exchange certainly can be extensible to support something like that, but the design work would be quite involved. - : 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