On Thu, 2005-06-02 at 09:46 -0700, Junio C Hamano wrote: > When a remote repository is deltified, we need to get the > objects that a deltified object we want to obtain is based upon. > The initial parts of each retrieved SHA1 file is inflated and > inspected to see if it is deltified, and its base object is > asked from the remote side when it is. Since this partial > inflation and inspection has a small performance hit, it can > optionally be skipped by giving -d flag to git-*-pull commands. > This flag should be used only when the remote repository is > known to have no deltified objects. Eww. Don't you want to attempt to get the referenced sha1 *before* you stick the delta blob into the repository? Otherwise, if a transfer fails, there's no good way to recover your database through the git-*pull interfaces, ie: Try to pull session 1: pull tree a pull delta b (references blob c) pull blob c -> fails! Try to pull session 2: pull tree a delta b - Found in database! ... Or do I not understand your code properly? (I'm working on a similar piece of code for my git-daemon protocol, which is why I'm worried about this issue) -- Jason McMullan <jason.mcmullan@timesys.com> TimeSys Corporation - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
This archive was generated by hypermail 2.1.8 : 2005-06-03 03:04:01 EST