"brian m. carlson" <[email protected]> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
