# What's in git.git 4 messages from 2006-02-20 to 2006-02-20. Participants: Junio C Hamano, Andreas Ericsson. Thread: https://gitlist.dev/t/3402 ## Junio C Hamano, 2006-02-20 07:57 Subject: What's in git.git Message-ID: <7v3bieea32.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v3bieea32.fsf%40assigned-by-dhcp.cox.net ``` The updated pack-object series is now in "next" branch, and seems to be cooking nicely. The "reuse from existing pack" change seems to be a huge win and I haven't found problems in there. There now is further performance improvements for git-send-pack to avoid sending a huge blob or tree object in its full representation when we know the other end has a suitable object to use as the base; instead we can just send it out deltified. The other end would expand it to a loose object and this would not make abit of difference in the resulting repository -- only the bandwidth requirement reduction is visible [*1*]. In principle, this is also applicable for fetch-pack, but it involves a bit of pack protocol change. The protocol extension mechanism was done nicely by Johannes a while ago, and we can use it to implement this with full backward compatibility. After a bit more testing, we might want to make --thin transfer the default (even without an option to turn it off -- I just do not see a point not to use it if it is bug-free). * The 'master' branch has these since the last announcement. Junio C Hamano: fmt-merge-msg: say which branch things were merged into unless 'master' Allow git-mv to accept ./ in paths. Documentation: fix typo in rev-parse --short option description. fmt-merge-msg: do not add excess newline at the end. Merge branch 'jc/mv' Merge branch 'jc/merge-msg' * The 'next' branch, in addition, has these. Johannes Schindelin: Fixes for ancient versions of GNU make avoid makefile override warning Really honour NO_PYTHON Junio C Hamano: Merge branch 'jc/merge-msg' into next Merge branch 'js/portable' into next rev-list --objects-edge Merge branch 'jc/rev-list' into next Thin pack - create packfile with missing delta base. send-pack --thin: use "thin pack" delta transfer. Merge branch 'jc/pack-thin' into next [Footnote] *1* The version of the patch I earlier sent to the list had a grave performance bug; please do not use it. The one in "next" branch has the bug fixed already. ``` ## Andreas Ericsson, 2006-02-20 08:34 Subject: Re: What's in git.git Message-ID: <43F97F0D.9080500@op5.se> URL: https://gitlist.dev/e/43F97F0D.9080500%40op5.se In-Reply-To: <7v3bieea32.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > The updated pack-object series is now in "next" branch, and > seems to be cooking nicely. The "reuse from existing pack" > change seems to be a huge win and I haven't found problems in > there. > Wonderful news. I'll cherry-pick them and do some further testing. > There now is further performance improvements for git-send-pack > to avoid sending a huge blob or tree object in its full > representation when we know the other end has a suitable object > to use as the base; instead we can just send it out deltified. > The other end would expand it to a loose object and this would > not make abit of difference in the resulting repository -- only > the bandwidth requirement reduction is visible [*1*]. > How likely is this to increase the CPU-power needed on the server-side? If there is a blob on the server-side, but far from the deltified object I suppose we have to look at each commit, perhaps only to discover that the client doesn't have them and we need to construct the blob anyways. > > After a bit more testing, we might want to make --thin transfer > the default (even without an option to turn it off -- I just do > not see a point not to use it if it is bug-free). > If the answer to my question above is "minimal to none", I agree most vehemently. ;) -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ``` ## Junio C Hamano, 2006-02-20 09:04 Subject: Re: What's in git.git Message-ID: <7vwtfqcsef.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vwtfqcsef.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <43F97F0D.9080500@op5.se> ``` Andreas Ericsson writes: > Junio C Hamano wrote: > >> There now is further performance improvements for git-send-pack >> to avoid sending a huge blob or tree object in its full >> representation when we know the other end has a suitable object >> to use as the base; instead we can just send it out deltified. >> The other end would expand it to a loose object and this would >> not make abit of difference in the resulting repository -- only >> the bandwidth requirement reduction is visible [*1*]. > > How likely is this to increase the CPU-power needed on the > server-side? If there is a blob on the server-side, but far from the > deltified object I suppose we have to look at each commit, perhaps > only to discover that the client doesn't have them and we need to > construct the blob anyways. Not much. It deliberately keeps the set of blobs and trees to consider for remote base to minimum -- just the trees contained in the boundary commits. That way we may miss the best base candidate that are further back in history, but it does not matter because even using the less optimum one as a base saves us from sending the base object at all. ``` ## Junio C Hamano, 2006-02-20 09:47 Subject: Re: What's in git.git Message-ID: <7vd5hicqfi.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vd5hicqfi.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <43F97F0D.9080500@op5.se> ``` Andreas Ericsson writes: > Junio C Hamano wrote: >> >> The updated pack-object series is now in "next" branch, and >> seems to be cooking nicely. The "reuse from existing pack" >> change seems to be a huge win and I haven't found problems in >> there. > > Wonderful news. I'll cherry-pick them and do some further testing. BTW, the point of "next" is that you do not have to necessarily cherry pick. The topic branches in there are supposed to be in testable shape. Having said that, you could disect them out if you wanted to: $ git log --pretty=oneline next | grep jc/pack- | head -n 8 5be4eabf90a4f6d14d3ae16772e6b2e063d71587 Merge branch 'jc/pack-thin' into next bb837eccf42e5e8bbd4fe0927e7fa2afcfd2b564 Merge branch 'jc/pack-thin' into next 416b3cb4303e1a13ed05413bef7a0c1b9f7fc09e Merge branch 'jc/pack-reuse' 07e8ab9be913bd50595707f21a896ac15c4f5a89 Merge branch 'jc/pack-reuse' The tip of jc/pack-reuse (that is the "reuse data from existing packs" topic branch) jc/pack-thin ("thin packs") are at 416b3c^2 and 5be4ea^2 respectively. So to check out the "reuse", you would: $ git branch -f jc/pack-reuse 416b3c^2 $ git pull . jc/pack-reuse If you want to try out "thin packs", you would need both pack-objects change and rev-list change (the tip of jc/rev-list is at 8c0db2^2). $ git branch -f jc/rev-list 8c0db2^2 $ git branch -f jc/pack-thin 5be4ea^2 $ git pull . jc/pack-thin $ git pull . jc/rev-list ```