[deleted]
Counting Objects
21–30 of 40 posts
Re: Counting Objects
#22Hopefully this isn't too off topic, does anyone know what software was used to make the charts in this post?
Re: Counting Objects
#23Perhaps I'm a bit ignorant of git's storage and protocols, but what's the purpose of this initial count? Seems to me it's traversing the tree twice - once to count and once to send the objects across the network. So why not traverse the tree, sending objects that need to be sent and ignoring the ones that don't instead of counting?
Re: Counting Objects
#24Perhaps I'm a bit ignorant of git's storage and protocols, but what's the purpose of this initial count? Seems to me it's traversing the tree twice - once to count and once to send the objects across the network. So why not traverse the tree, sending objects that need to be sent and ignoring the ones that don't instead of counting?
[deleted]
Re: Counting Objects
#25Perhaps I'm a bit ignorant of git's storage and protocols, but what's the purpose of this initial count? Seems to me it's traversing the tree twice - once to count and once to send the objects across the network. So why not traverse the tree, sending objects that need to be sent and ignoring the ones that don't instead of counting?
You need to know which objects are reachable before you can delta compress them (or reuse a packed delta chain). I guess you could restrict compression antecedents to graph ancestors in your pack, but at the cost of not compressing similar siblings (and blobs are leaves).
Re: Counting Objects
#26Not specific to the post, but:
> we're sending few objects, all from the tip of the repository, and these objects will usually be delta'ed against older objects that won't be sent. Therefore, Git tries to find new delta bases for these objects.
Why is this the case ? git can send thin packs if the receiver already has the objects, why does it still need to find a full base to diff against ? (Not counting when initial base objects are from another fork -- I don't know if it's often the case)
On top of that as far as I understood from the discussion about heuristics (https://git.kernel.org/cgit/git/git.git/tree/Documentation/t...) it seems like the latest objects are full and the earlier objects are diffed against them (double benefits: you usually want access to the last object which is already full, and earlier objects tend to be only remove stuff, not add because "stuff grows over time). So if objects are still stored as packs, things should already be in a pretty good shape to be sent as-is... or not ?
Re: Counting Objects
#27Hopefully this isn't too off topic, does anyone know what software was used to make the charts in this post?
Judging by the water colors I'm guessing Paper by FiftyThree.
Re: Counting Objects
#28So does GitHub hire C engineers? Git is implemented in C.
Yes. We have open positions for C engineers.
Re: Counting Objects
#29Earlier quoted context omitted.
Ruby MRI and YARV are both written in C, so to be a true Ruby hacker you need some C chops. :-)
Interesting. I've heard that thrown around before, but I've never heard someone say the same thing about Python, even though the main Python implementation is C.
From the Python docs:
Extending and Embedding tutorial for C/C++ programmers
Python/C API reference for C/C++ programmers
... right between "Distributing Python Modules" and "FAQs"
Re: Counting Objects
#30Earlier quoted context omitted.
Ruby MRI and YARV are both written in C, so to be a true Ruby hacker you need some C chops. :-)
Interesting. I've heard that thrown around before, but I've never heard someone say the same thing about Python, even though the main Python implementation is C.
From my own experience with Ruby and MRI, there's quite a strong culture of "transparency of code". It's not unusual if you're really down into some "interesting" problem to delve first into your gems/frameworks, and eventually even into MRI itself. Being a PL polyglot pays off in spades in these cases, since you get a solid understanding of the underpinnings of everything.
Note that there's very rarely any need to go there, but the fact that it's both possible and culturally encouraged makes a huge difference for those of us who've needed it.