Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [RFC] pack-objects: compression level for non-blobs

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:55:37

Duy Nguyen [off-list ref] writes:
On Tue, Jan 1, 2013 at 11:15 AM, Duy Nguyen [off-list ref] wrote:
quoted
quoted
Fix pack-objects to behave the way JGit does, cluster commits first in
the pack stream. Now you have a dense space of commits. If I remember
right this has a tiny positive improvement for most rev-list
operations with very little downside.
I was going to suggest a similar thing. The current state of C Git's
pack writing is not bad. We mix commits and tags together, but tags
And I was wrong. At least since 1b4bb16 (pack-objects: optimize
"recency order" - 2011-06-30) commits are spread out and can be mixed
with trees too.
Really?  That certainly wasn't the intention of that change.

The compute_write_order() function first fills the commits in the
original recency order (the order in which rev-list discovered them
by traversing the history from the tips) until we find a commit that
is tagged by a ref in the refs/tags/ hierarchy.  When we reach that
point, we stop showing the commits and show all the tags in the
refs/tags/ hierarchy and commits that are tagged by them, breaking
the original ordering of commits so that ancient but tagged commits
clump at this point.  After that, we resume showing the rest of the
commits and tags in the original order they came to us.  Trees are
done next, and then the remainder.

So I am not sure how trees can appear between commits.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help