# Add note about IANA confirmation 3 messages from 2005-09-12 to 2005-09-12. Participants: Linus Torvalds, Junio C Hamano. Thread: https://gitlist.dev/t/1784 ## Linus Torvalds, 2005-09-12 18:23 Subject: Add note about IANA confirmation Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0509121057520.3242%40g5.osdl.org ``` The git port (9418) is officially listed by IANA now. So document it. Signed-off-by: Linus Torvalds --- Btw, another thing happened yesterday too: I'm now officially using a packed archive for my core kernel stuff. The format hasn't changed in I-don't-know-how-long, and I can't recall any pack-specific bug either (apart from the obvious lack of support by some of the client-side stuff). Goodie. Me happy. diff --git a/cache.h b/cache.h --- a/cache.h +++ b/cache.h @@ -50,6 +50,17 @@ * Your search - "port 9418" - did not match any documents. * * as www.google.com puts it. + * + * This port has been properly assigned for git use by IANA: + * git (Assigned-9418) [I06-050728-0001]. + * + * git 9418/tcp git pack transfer service + * git 9418/udp git pack transfer service + * + * with Linus Torvalds as the point of + * contact. September 2005. + * + * See http://www.iana.org/assignments/port-numbers */ #define DEFAULT_GIT_PORT 9418 ``` ## Junio C Hamano, 2005-09-12 21:41 Subject: Re: Add note about IANA confirmation Message-ID: <7vk6hm7ymd.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vk6hm7ymd.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Linus Torvalds writes: > The git port (9418) is officially listed by IANA now. Thanks. Applied. > Btw, another thing happened yesterday too: I'm now officially using a > packed archive for my core kernel stuff. The format hasn't changed in > I-don't-know-how-long, and I can't recall any pack-specific bug either > (apart from the obvious lack of support by some of the client-side stuff). You are brave ;-). Seriously, packed archive seems to be really stable. I've been on packed archive for git.git for quite some time now, and all of my recent read-tree and merge experiments have been done on a linux-2.6 repository that has several maintainer trees rolled into a single big ball of wax, packed into one pack that weighs about 76MB, with a few handred unpacked objects. I noticed one thing that is a bit curious. Packing the same set of objects with --window=50 seems to give worse packing result (space-wise) than with --window=10, which is the default if I recall correctly. : siamese; git-rev-list --objects v2.6.12 >++object-list-2.6.12 : siamese; git-pack-objects --window=50 --stdout \ <./++object-list-2.6.12 >./++pack-w50.pack Packing 31617 objects : siamese; git-pack-objects --window=10 --stdout \ <./++object-list-2.6.12 >./++pack-w10.pack Packing 31617 objects : siamese; ls -l ./++pack-w*.pack -rw-rw-r-- 1 junio src 57240724 Sep 12 14:39 ./++pack-w10.pack -rw-rw-r-- 1 junio src 57411879 Sep 12 14:37 ./++pack-w50.pack BTW, I happen to know one pathological case where 'git repack' would do a wrong thing and abort, but it is really of "doctor if I do this it hurts -- do not do it then" kind, so it is not on my priority list right now. ``` ## Linus Torvalds, 2005-09-12 22:40 Subject: Re: Add note about IANA confirmation Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0509121523170.3266%40g5.osdl.org In-Reply-To: <7vk6hm7ymd.fsf@assigned-by-dhcp.cox.net> ``` On Mon, 12 Sep 2005, Junio C Hamano wrote: > > I noticed one thing that is a bit curious. Packing the same set > of objects with --window=50 seems to give worse packing result > (space-wise) than with --window=10, which is the default if I > recall correctly. The window doesn't seem to make much of a difference any more, now that we sort object blobs by filename. I suspect that it's just being unlucky: it finds a locally smaller diff and uses it, but then that ends up causing some other delta to _not_ be generated, because that would overflow the "--depth". At least I _think_ that's the case. Maybe there's something really wrong in the window handling. Generally, it's cheaper and more efficient to just increase the "depth" rather than the "window". Of course, that has a possibly very bad run-time overhead at unpacking time, so increasing it too much is bad. Quick test (maybe I did it right, maybe I didn't): window=10 window=50 depth=10 57240724 57411879 depth=50 56700053 56808913 depth=inf 56603101 56541663 ie "--window=50" is actually worse than "--window=10" for depths 10 and 50, but better for the "infinite" depth case (approximated by using "--depth=50000" which is practically infinite, since I just packed the 2.6.12 history with less than 50,000 objects ;) Of course, the 2.6.12 tree is not a good pack object. Half the objects in that tree have no history at all. It's not clear that it's particularly representative of any real long-term history. Linus ```