threads / discuss / 1784

Add note about IANA confirmation

Subject: Add note about IANA confirmation

## tl;dr

3 messages between Sep 12, 2005 and Sep 12, 2005.

replies: 2people: 2as markdown or json

Linus Torvalds· Sep 12, 2005, 18:23 UTC · lore

The git port (9418) is officially listed by IANA now.

So document it.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---

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 <torvalds@osdl.org> as the point of
+ * contact. September 2005.
+ *
+ * See http://www.iana.org/assignments/port-numbers
  */
 #define DEFAULT_GIT_PORT 9418

Junio C Hamano· Sep 12, 2005, 21:41 UTC · re: Linus Torvalds · lore

Re: Add note about IANA confirmation

Linus Torvalds <torvalds@osdl.org> 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· Sep 12, 2005, 22:40 UTC · re: Junio C Hamano · lore

Re: Add note about IANA confirmation

On Mon, 12 Sep 2005, Junio C Hamano wrote:

Show 5 quoted lines

> 
> 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