Re: [PATCH v2 2/8] Apply object_id Coccinelle transformations.

[Junio C Hamano <gitster@pobox.com>]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> Apply the set of semantic patches from contrib/examples/coccinelle to
> convert some leftover places using struct object_id's hash member to
> instead use the wrapper functions that take struct object_id natively.

It is somewhat curious how these 'some leftover places' are chosen.

Especially, this hunk was interesting.

> diff --git a/refs/files-backend.c b/refs/files-backend.c
> index 1f380764..dac3a222 100644
> --- a/refs/files-backend.c
> +++ b/refs/files-backend.c
> @@ -1725,14 +1725,14 @@ static int verify_lock(struct ref_lock *lock,
>  			errno = save_errno;
>  			return -1;
>  		} else {
> -			hashclr(lock->old_oid.hash);
> +			oidclr(&lock->old_oid);
>  			return 0;
>  		}
>  	}
>  	if (old_sha1 && hashcmp(lock->old_oid.hash, old_sha1)) {
>  		strbuf_addf(err, "ref %s is at %s but expected %s",
>  			    lock->ref_name,
> -			    sha1_to_hex(lock->old_oid.hash),
> +			    oid_to_hex(&lock->old_oid),
>  			    sha1_to_hex(old_sha1));
>  		errno = EBUSY;
>  		return -1;

The function gets old_sha1 which is the old-world "const unsigned
char *" that is passed via lock_ref_sha1_basic() from public entry
points like rename_ref() and ref_transaction_commit().  As this
codepath and the functions involved have not be converted to oid,
we end up seeing oid_to_hex() next to sha1_to_hex() ;-)

Not a complaint; this is how we make progress incrementally.

It was just I noticed this function is left in a somewhat funny
intermediate state after this step.

Thanks.