Re: [PATCH v2 0/4] rename "sha1-foo" files

[Derrick Stolee <stolee@gmail.com>]

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