Message ID | cover.1609415114.git.martin.agren@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | rename "sha1-foo" files | expand |
On 12/31/2020 6:56 AM, Martin Ågren wrote: > Thanks to Derrick and brian for commenting on v1 [1] of my series for > renaming sha1-foo files and generalizing "sha", "sha1" and so on in > them. I realized I hadn't renamed the header guard in hash-lookup.h as I > renamed the file. That made me realize that I had failed to look for > "SHA-1" (capital letters). So this v2 is a bit bigger than v1, but not > by too much, I think. The range-diff is below. Makes sense. Thanks for being diligent! > Range-diff against v1: > 1: aac3a3c3e2 ! 1: 4d69d448a3 object-name.c: rename from sha1-name.c > @@ Commit message > Generalize the last remnants of "sha" and "sha1" in this file and rename > it to reflect that we're not just able to handle SHA-1 these days. > > + We need to update one test to check for an updated error string. > + > Signed-off-by: Martin Ågren <martin.agren@gmail.com> > > + ## t/t1512-rev-parse-disambiguation.sh ## > +@@ t/t1512-rev-parse-disambiguation.sh: test_expect_success 'blob and tree' ' > + > + test_expect_success 'warn ambiguity when no candidate matches type hint' ' > + test_must_fail git rev-parse --verify 000000000^{commit} 2>actual && > +- test_i18ngrep "short SHA1 000000000 is ambiguous" actual > ++ test_i18ngrep "short object ID 000000000 is ambiguous" actual > + ' > + > + test_expect_success 'disambiguate tree-ish' ' > + > ## list-objects-filter.c ## > @@ > * in the traversal (until we mark it SEEN). This is a way to > @@ object-name.c: static void unique_in_pack(struct packed_git *p, > break; > update_candidates(ds, &oid); > } > +@@ object-name.c: static enum get_oid_result get_short_oid(struct repository *r, > + if (!quietly && (status == SHORT_NAME_AMBIGUOUS)) { > + struct oid_array collect = OID_ARRAY_INIT; > + > +- error(_("short SHA1 %s is ambiguous"), ds.hex_pfx); > ++ error(_("short object ID %s is ambiguous"), ds.hex_pfx); > + > + /* > + * We may still have ambiguity if we simply saw a series of > @@ object-name.c: static enum get_oid_result get_oid_with_context_1(struct repository *repo, > if (!ret) > return ret; > 2: 4243886d8a ! 2: 7ab29b868f object-file.c: rename from sha1-file.c > @@ sha1-file.c => object-file.c > * creation etc. > */ > #include "cache.h" > +@@ object-file.c: static int alt_odb_usable(struct raw_object_store *o, > + * LF separated. Its base points at a statically allocated buffer that > + * contains "/the/directory/corresponding/to/.git/objects/...", while > + * its name points just after the slash at the end of ".git/objects/" > +- * in the example above, and has enough space to hold 40-byte hex > +- * SHA1, an extra slash for the first level indirection, and the > +- * terminating NUL. > ++ * in the example above, and has enough space to hold all hex characters > ++ * of the object ID, an extra slash for the first level indirection, and > ++ * the terminating NUL. > + */ > + static void read_info_alternates(struct repository *r, > + const char *relative_base, > > ## Makefile ## > @@ Makefile: LIB_OBJS += notes-cache.o > 3: 8d3b123633 = 3: 91617de0ac sha1-lookup: rename `sha1_pos()` as `hash_pos()` > 4: afee010474 ! 4: 9df53353dc hash-lookup: rename from sha1-lookup > @@ Commit message > Signed-off-by: Martin Ågren <martin.agren@gmail.com> > > ## sha1-lookup.h => hash-lookup.h ## > +@@ > +-#ifndef SHA1_LOOKUP_H > +-#define SHA1_LOOKUP_H > ++#ifndef HASH_LOOKUP_H > ++#define HASH_LOOKUP_H > + > + typedef const unsigned char *hash_access_fn(size_t index, void *table); > + > @@ hash-lookup.h: int hash_pos(const unsigned char *hash, > hash_access_fn fn); This range-diff looks sensible. I approve v2. Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Thanks, -Stolee
On Thu, 31 Dec 2020 at 13:48, Derrick Stolee <stolee@gmail.com> wrote: > > On 12/31/2020 6:56 AM, Martin Ågren wrote: > > "SHA-1" (capital letters). So this v2 is a bit bigger than v1, but not > > by too much, I think. The range-diff is below. > > Makes sense. Thanks for being diligent! > This range-diff looks sensible. I approve v2. > > Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Thanks, Stolee! Martin