{"thread":{"id":"3402","subject":"What's in git.git","startedAt":"2006-02-20T07:57:37Z","lastAt":"2006-02-20T09:47:29Z","messageCount":4,"participants":["Junio C Hamano","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"16441","messageId":"7v3bieea32.fsf@assigned-by-dhcp.cox.net","threadId":"3402","inReplyTo":null,"subject":"What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-20T07:57:37Z","receivedAt":"2006-02-20T07:57:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The updated pack-object series is now in \"next\" branch, and\nseems to be cooking nicely. The \"reuse from existing pack\"\nchange seems to be a huge win and I haven't found problems in\nthere.\n\nThere now is further performance improvements for git-send-pack\nto avoid sending a huge blob or tree object in its full\nrepresentation when we know the other end has a suitable object\nto use as the base; instead we can just send it out deltified.\nThe other end would expand it to a loose object and this would\nnot make abit of difference in the resulting repository -- only\nthe bandwidth requirement reduction is visible [*1*].\n\nIn principle, this is also applicable for fetch-pack, but it\ninvolves a bit of pack protocol change. The protocol extension\nmechanism was done nicely by Johannes a while ago, and we can\nuse it to implement this with full backward compatibility.\n\nAfter a bit more testing, we might want to make --thin transfer\nthe default (even without an option to turn it off -- I just do\nnot see a point not to use it if it is bug-free).\n\n* The 'master' branch has these since the last announcement.\n\nJunio C Hamano:\n fmt-merge-msg: say which branch things were merged into unless 'master'\n Allow git-mv to accept ./ in paths.\n Documentation: fix typo in rev-parse --short option description.\n fmt-merge-msg: do not add excess newline at the end.\n Merge branch 'jc/mv'\n Merge branch 'jc/merge-msg'\n\n\n* The 'next' branch, in addition, has these.\n\nJohannes Schindelin:\n Fixes for ancient versions of GNU make\n avoid makefile override warning\n Really honour NO_PYTHON\n\nJunio C Hamano:\n Merge branch 'jc/merge-msg' into next\n Merge branch 'js/portable' into next\n rev-list --objects-edge\n Merge branch 'jc/rev-list' into next\n Thin pack - create packfile with missing delta base.\n send-pack --thin: use \"thin pack\" delta transfer.\n Merge branch 'jc/pack-thin' into next\n\n\n[Footnote]\n\n*1* The version of the patch I earlier sent to the list had a\ngrave performance bug; please do not use it. The one in \"next\"\nbranch has the bug fixed already.\n"},{"id":"16442","messageId":"43F97F0D.9080500@op5.se","threadId":"3402","inReplyTo":"7v3bieea32.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-02-20T08:34:21Z","receivedAt":"2006-02-20T08:34:21Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> The updated pack-object series is now in \"next\" branch, and\n> seems to be cooking nicely. The \"reuse from existing pack\"\n> change seems to be a huge win and I haven't found problems in\n> there.\n> \n\nWonderful news. I'll cherry-pick them and do some further testing.\n\n> There now is further performance improvements for git-send-pack\n> to avoid sending a huge blob or tree object in its full\n> representation when we know the other end has a suitable object\n> to use as the base; instead we can just send it out deltified.\n> The other end would expand it to a loose object and this would\n> not make abit of difference in the resulting repository -- only\n> the bandwidth requirement reduction is visible [*1*].\n> \n\nHow likely is this to increase the CPU-power needed on the server-side? \nIf there is a blob on the server-side, but far from the deltified object \nI suppose we have to look at each commit, perhaps only to discover that \nthe client doesn't have them and we need to construct the blob anyways.\n\n> \n> After a bit more testing, we might want to make --thin transfer\n> the default (even without an option to turn it off -- I just do\n> not see a point not to use it if it is bug-free).\n> \n\nIf the answer to my question above is \"minimal to none\", I agree most \nvehemently. ;)\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"16443","messageId":"7vwtfqcsef.fsf@assigned-by-dhcp.cox.net","threadId":"3402","inReplyTo":"43F97F0D.9080500@op5.se","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-20T09:04:56Z","receivedAt":"2006-02-20T09:04:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> Junio C Hamano wrote:\n>\n>> There now is further performance improvements for git-send-pack\n>> to avoid sending a huge blob or tree object in its full\n>> representation when we know the other end has a suitable object\n>> to use as the base; instead we can just send it out deltified.\n>> The other end would expand it to a loose object and this would\n>> not make abit of difference in the resulting repository -- only\n>> the bandwidth requirement reduction is visible [*1*].\n>\n> How likely is this to increase the CPU-power needed on the\n> server-side? If there is a blob on the server-side, but far from the\n> deltified object I suppose we have to look at each commit, perhaps\n> only to discover that the client doesn't have them and we need to\n> construct the blob anyways.\n\nNot much. It deliberately keeps the set of blobs and trees to\nconsider for remote base to minimum -- just the trees contained\nin the boundary commits. That way we may miss the best base\ncandidate that are further back in history, but it does not\nmatter because even using the less optimum one as a base saves\nus from sending the base object at all.\n"},{"id":"16445","messageId":"7vd5hicqfi.fsf@assigned-by-dhcp.cox.net","threadId":"3402","inReplyTo":"43F97F0D.9080500@op5.se","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-20T09:47:29Z","receivedAt":"2006-02-20T09:47:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> Junio C Hamano wrote:\n>>\n>> The updated pack-object series is now in \"next\" branch, and\n>> seems to be cooking nicely. The \"reuse from existing pack\"\n>> change seems to be a huge win and I haven't found problems in\n>> there.\n>\n> Wonderful news. I'll cherry-pick them and do some further testing.\n\nBTW, the point of \"next\" is that you do not have to necessarily\ncherry pick. The topic branches in there are supposed to be in\ntestable shape.\n\nHaving said that, you could disect them out if you wanted to:\n\n$ git log --pretty=oneline next | grep jc/pack- | head -n 8\n5be4eabf90a4f6d14d3ae16772e6b2e063d71587 Merge branch 'jc/pack-thin' into next\nbb837eccf42e5e8bbd4fe0927e7fa2afcfd2b564 Merge branch 'jc/pack-thin' into next\n416b3cb4303e1a13ed05413bef7a0c1b9f7fc09e Merge branch 'jc/pack-reuse'\n07e8ab9be913bd50595707f21a896ac15c4f5a89 Merge branch 'jc/pack-reuse'\n\nThe tip of jc/pack-reuse (that is the \"reuse data from existing\npacks\" topic branch) jc/pack-thin (\"thin packs\") are at 416b3c^2\nand 5be4ea^2 respectively.\n\nSo to check out the \"reuse\", you would:\n\n$ git branch -f jc/pack-reuse 416b3c^2\n$ git pull . jc/pack-reuse\n\nIf you want to try out \"thin packs\", you would need both\npack-objects change and rev-list change (the tip of jc/rev-list\nis at 8c0db2^2).\n\n$ git branch -f jc/rev-list 8c0db2^2\n$ git branch -f jc/pack-thin 5be4ea^2\n$ git pull . jc/pack-thin\n$ git pull . jc/rev-list\n"}]}