git/builtin/bundle.c, branch v2.32.2

Merge branch 'bc/sha-256-part-3'

2020-08-12T01:04:11Z

The final leg of SHA-256 transition. * bc/sha-256-part-3: (39 commits) t: remove test_oid_init in tests docs: add documentation for extensions.objectFormat ci: run tests with SHA-256 t: make SHA1 prerequisite depend on default hash t: allow testing different hash algorithms via environment t: add test_oid option to select hash algorithm repository: enable SHA-256 support by default setup: add support for reading extensions.objectformat bundle: add new version for use with SHA-256 builtin/verify-pack: implement an --object-format option http-fetch: set up git directory before parsing pack hashes t0410: mark test with SHA1 prerequisite t5308: make test work with SHA-256 t9700: make hash size independent t9500: ensure that algorithm info is preserved in config t9350: make hash size independent t9301: make hash size independent t9300: use $ZERO_OID instead of hard-coded object ID t9300: abstract away SHA-1-specific constants t8011: make hash size independent ...

bundle: add new version for use with SHA-256

2020-07-30T16:16:48Z

Currently we detect the hash algorithm in use by the length of the object ID. This is inelegant and prevents us from using a different hash algorithm that is also 256 bits in length. Since we cannot extend the v2 format in a backward-compatible way, let's add a v3 format, which is identical, except for the addition of capabilities, which are prefixed by an at sign. We add "object-format" as the only capability and reject unknown capabilities, since we do not have a network connection and therefore cannot negotiate with the other side. For compatibility, default to the v2 format for SHA-1 and require v3 for SHA-256. In t5510, always use format v3 so we can be sure we produce consistent results across hash algorithms. Since head -n N lists the top N lines instead of the Nth line, let's run our output through sed to normalize it and compare it against a fixed value, which will make sure we get exactly what we're expecting. Signed-off-by: brian m. carlson Reviewed-by: Eric Sunshine Signed-off-by: Junio C Hamano

strvec: convert builtin/ callers away from argv_array name

2020-07-28T22:02:18Z

We eventually want to drop the argv_array name and just use strvec consistently. There's no particular reason we have to do it all at once, or care about interactions between converted and unconverted bits. Because of our preprocessor compat layer, the names are interchangeable to the compiler (so even a definition and declaration using different names is OK). This patch converts all of the files in builtin/ to keep the diff to a manageable size. The conversion was done purely mechanically with: git ls-files '*.c' '*.h' | xargs perl -i -pe ' s/ARGV_ARRAY/STRVEC/g; s/argv_array/strvec/g; ' and then selectively staging files with "git add builtin/". We'll deal with any indentation/style fallouts separately. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

strvec: rename files from argv-array to strvec

2020-07-28T22:02:17Z

This requires updating #include lines across the code-base, but that's all fairly mechanical, and was done with: git ls-files '*.c' '*.h' | xargs perl -i -pe 's/argv-array.h/strvec.h/' Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

bundle-verify: add --quiet

2019-11-11T02:46:29Z

Add --quiet to git-bundle verify as proposed on the mailing list [1]. Reference: https://www.mail-archive.com/git@vger.kernel.org/msg182844.html Signed-off-by: Robin H. Johnson Signed-off-by: Junio C Hamano

bundle-create: progress output control

2019-11-11T02:46:28Z

Support the progress output options from pack-objects in git-bundle's create subcommand. Most notably, this provides --quiet as requested on the git mailing list per [1] Reference: https://www.mail-archive.com/git@vger.kernel.org/msg182844.html Signed-off-by: Robin H. Johnson Signed-off-by: Junio C Hamano

bundle: framework for options before bundle file

2019-11-11T02:46:26Z

Make it possible for any of the git-bundle subcommands to include options: - before the sub-command - after the sub-command, before the bundle filename There is an immediate gain in support for help with all of the sub-commands, where 'git bundle list-heads -h' previously returned an error. Downside here is an increase in code duplication that cannot be trivially avoided short of shared global static options. Signed-off-by: Robin H. Johnson Signed-off-by: Junio C Hamano

create_bundle(): drop unused "header" parameter

2019-01-24T20:35:44Z

There's no need to pass a header struct to create_bundle(); it writes the header information directly to a descriptor (and does not report back details to the caller). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

bundle.c: remove the_repository references

2018-11-12T05:50:06Z

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

bundle: use prefix_filename with bundle path

2017-03-21T18:18:41Z

We may take the path to a bundle file as an argument, and need to adjust the filename based on the prefix we discovered while setting up the git directory. We do so manually into a fixed-size buffer, but using prefix_filename() is the normal way. Besides being more concise, there are two subtle improvements: 1. The original inserted a "/" between the two paths, even though the "prefix" argument always has the "/" appended. That means that: cd subdir && git bundle verify ../foo.bundle was looking at (and reporting) subdir//../foo.bundle. Harmless, but ugly. Using prefix_filename() gets this right. 2. The original checked for an absolute path by looking for a leading '/'. It should have been using is_absolute_path(), which also covers more cases on Windows (backslashes and dos drive prefixes). But it's easier still to just pass the name to prefix_filename(), which handles this case automatically. Note that we'll just leak the resulting buffer in the name of simplicity, since it needs to last through the duration of the program anyway. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano