<feed xmlns='http://www.w3.org/2005/Atom'>
<title>git/builtin-count-objects.c, branch v1.5.0-rc3</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/git/git.git/
</subtitle>
<id>https://git.shady.money/git/atom?h=v1.5.0-rc3</id>
<link rel='self' href='https://git.shady.money/git/atom?h=v1.5.0-rc3'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/git/'/>
<updated>2006-12-27T09:05:00Z</updated>
<entry>
<title>count-objects -v: show number of packs as well.</title>
<updated>2006-12-27T09:05:00Z</updated>
<author>
<name>Junio C Hamano</name>
<email>junkio@cox.net</email>
</author>
<published>2006-12-27T09:04:03Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/git/commit/?id=ae72f685418b79bbd67e1017c5b1ac7d731c042e'/>
<id>urn:sha1:ae72f685418b79bbd67e1017c5b1ac7d731c042e</id>
<content type='text'>
Recent "git push" keeps transferred objects packed much more aggressively
than before.  Monitoring output from git-count-objects -v for number of
loose objects is not enough to decide when to repack -- having too many
small packs is also a good cue for repacking.

Signed-off-by: Junio C Hamano &lt;junkio@cox.net&gt;
</content>
</entry>
<entry>
<title>pack-objects --unpacked=&lt;existing pack&gt; option.</title>
<updated>2006-09-07T09:46:03Z</updated>
<author>
<name>Junio C Hamano</name>
<email>junkio@cox.net</email>
</author>
<published>2006-09-06T09:12:09Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/git/commit/?id=106d710bc13f34aec1a15c4cff80f062f384edf6'/>
<id>urn:sha1:106d710bc13f34aec1a15c4cff80f062f384edf6</id>
<content type='text'>
Incremental repack without -a essentially boils down to:

	rev-list --objects --unpacked --all |
        pack-objects $new_pack

which picks up all loose objects that are still live and creates
a new pack.

This implements --unpacked=&lt;existing pack&gt; option to tell the
revision walking machinery to pretend as if objects in such a
pack are unpacked for the purpose of object listing.  With this,
we could say:

	rev-list --objects --unpacked=$active_pack --all |
	pack-objects $new_pack

instead, to mean "all live loose objects but pretend as if
objects that are in this pack are also unpacked".  The newly
created pack would be perfect for updating $active_pack by
replacing it.

Since pack-objects now knows how to do the rev-list's work
itself internally, you can also write the above example by:

	pack-objects --unpacked=$active_pack --all $new_pack &lt;/dev/null

Signed-off-by: Junio C Hamano &lt;junkio@cox.net&gt;
</content>
</entry>
<entry>
<title>builtins: Makefile clean-up</title>
<updated>2006-08-04T08:51:04Z</updated>
<author>
<name>Junio C Hamano</name>
<email>junkio@cox.net</email>
</author>
<published>2006-08-04T08:51:04Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/git/commit/?id=f754fa9c5480c4556ad268fb5014c4b96cc7b9dc'/>
<id>urn:sha1:f754fa9c5480c4556ad268fb5014c4b96cc7b9dc</id>
<content type='text'>
This cleans up the build procedure for built-in commands by:

 - generating mostly redundant definition of BUILT_INS from
   BUILTIN_OBJS in the Makefile,
 - renaming a few files to make the above possible, and
 - sorting the built-in command table in git.c.

It might be a good idea to binary search (or perfect hash) the built-in
command table, but that can be done later when somebody feels like.

Signed-off-by: Junio C Hamano &lt;junkio@cox.net&gt;
</content>
</entry>
</feed>
