git/builtin/pack-objects.c, branch v2.0.2

Merge branch 'jk/pack-bitmap'

2014-04-08T19:00:33Z

* jk/pack-bitmap: pack-objects: do not reuse packfiles without --delta-base-offset add `ignore_missing_links` mode to revwalk

Merge branch 'jl/nor-or-nand-and'

2014-04-08T19:00:28Z

Eradicate mistaken use of "nor" (that is, essentially "nor" used not in "neither A nor B" ;-)) from in-code comments, command output strings, and documentations. * jl/nor-or-nand-and: code and test: fix misuses of "nor" comments: fix misuses of "nor" contrib: fix misuses of "nor" Documentation: fix misuses of "nor"

pack-objects: do not reuse packfiles without --delta-base-offset

2014-04-04T22:29:44Z

When we are sending a packfile to a remote, we currently try to reuse a whole chunk of packfile without bothering to look at the individual objects. This can make things like initial clones much lighter on the server, as we can just dump the packfile bytes. However, it's possible that the other side cannot read our packfile verbatim. For example, we may have objects stored as OFS_DELTA, but the client is an antique version of git that only understands REF_DELTA. We negotiate this capability over the fetch protocol. A normal pack-objects run will convert OFS_DELTA into REF_DELTA on the fly, but the "reuse pack" code path never even looks at the objects. This patch disables packfile reuse if the other side is missing any capabilities that we might have used in the on-disk pack. Right now the only one is OFS_DELTA, but we may need to expand in the future (e.g., if packv4 introduces new object types). We could be more thorough and only disable reuse in this case when we actually have an OFS_DELTA to send, but: 1. We almost always will have one, since we prefer OFS_DELTA to REF_DELTA when possible. So this case would almost never come up. 2. Looking through the objects defeats the purpose of the optimization, which is to do as little work as possible to get the bytes to the remote. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

comments: fix misuses of "nor"

2014-03-31T22:29:27Z

Signed-off-by: Justin Lebar Signed-off-by: Junio C Hamano

Merge branch 'jk/pack-bitmap-progress'

2014-03-28T20:50:56Z

The progress output while repacking and transferring objects showed an apparent large silence while writing the objects out of existing packfiles, when the reachability bitmap was in use. * jk/pack-bitmap-progress: pack-objects: show reused packfile objects in "Counting objects" pack-objects: show progress for reused packfiles

Merge branch 'jk/pack-bitmap'

2014-03-28T20:50:50Z

Instead of dying when asked to (re)pack with the reachability bitmap when a bitmap cannot be built, just (re)pack without producing a bitmap in such a case, with a warning. * jk/pack-bitmap: pack-objects: turn off bitmaps when skipping objects

Merge branch 'nd/upload-pack-shallow'

2014-03-21T19:49:08Z

Serving objects from a shallow repository needs to write a temporary file to be used, but the serving upload-pack may not have write access to the repository which is meant to be read-only. Instead feed these temporary shallow bounds from the standard input of pack-objects so that we do not have to use a temporary file. * nd/upload-pack-shallow: upload-pack: send shallow info over stdin to pack-objects

Merge branch 'sh/finish-tmp-packfile'

2014-03-18T20:50:24Z

* sh/finish-tmp-packfile: finish_tmp_packfile():use strbuf for pathname construction

Merge branch 'dd/use-alloc-grow'

2014-03-18T20:50:21Z

Replace open-coded reallocation with ALLOC_GROW() macro. * dd/use-alloc-grow: sha1_file.c: use ALLOC_GROW() in pretend_sha1_file() read-cache.c: use ALLOC_GROW() in add_index_entry() builtin/mktree.c: use ALLOC_GROW() in append_to_tree() attr.c: use ALLOC_GROW() in handle_attr_line() dir.c: use ALLOC_GROW() in create_simplify() reflog-walk.c: use ALLOC_GROW() replace_object.c: use ALLOC_GROW() in register_replace_object() patch-ids.c: use ALLOC_GROW() in add_commit() diffcore-rename.c: use ALLOC_GROW() diff.c: use ALLOC_GROW() commit.c: use ALLOC_GROW() in register_commit_graft() cache-tree.c: use ALLOC_GROW() in find_subtree() bundle.c: use ALLOC_GROW() in add_to_ref_list() builtin/pack-objects.c: use ALLOC_GROW() in check_pbase_path()

pack-objects: turn off bitmaps when skipping objects

2014-03-17T22:02:39Z

The pack bitmap format requires that we have a single bit for each object in the pack, and that each object's bitmap represents its complete set of reachable objects. Therefore we have no way to represent the bitmap of an object which references objects outside the pack. We notice this problem while generating the bitmaps, as we try to find the offset of a particular object and realize that we do not have it. In this case we die, and neither the bitmap nor the pack is generated. This is correct, but perhaps a little unfriendly. If you have bitmaps turned on in the config, many repacks will fail which would otherwise succeed. E.g., incremental repacks, repacks with "-l" when you have alternates, ".keep" files. Instead, this patch notices early that we are omitting some objects from the pack and turns off bitmaps (with a warning). Note that this is not strictly correct, as it's possible that the object being omitted is not reachable from any other object in the pack. In practice, this is almost never the case, and there are two advantages to doing it this way: 1. The code is much simpler, as we do not have to cleanly abort the bitmap-generation process midway through. 2. We do not waste time partially generating bitmaps only to find out that some object deep in the history is not being packed. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano