Re: [PATCH 3/5] match-trees: use hashcpy to splice trees
- From
Jeff King <peff@peff.net>
- Date
- Jan 10, 2019, 06:45 UTC
- Message-ID
- <20190110064520.GC20497@sigill.intra.peff.net>
- In-Reply-To
- <20190110042551.915769-4-sandals@crustytoothpaste.net>
On Thu, Jan 10, 2019 at 04:25:49AM +0000, brian m. carlson wrote:
Show 23 quoted lines
> When we're splicing trees, we're writing directly from one location into
> a buffer that is exactly the same size as a tree object. If the current
> hash algorithm is SHA-1, we may not have a full 32 (GIT_MAX_RAWSZ) bytes
> available to write, nor would we want to write that many bytes even if
> we did. In a future commit, we'll split out hashcpy to respect
> the_hash_algo while oidcpy uses GIT_MAX_RAWSZ, so convert the oidcpy to
> a hashcpy so we copy the right number of bytes.
>
> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
> ---
> match-trees.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/match-trees.c b/match-trees.c
> index feca48a5fd..b1fbd022d1 100644
> --- a/match-trees.c
> +++ b/match-trees.c
> @@ -224,7 +224,7 @@ static int splice_tree(const struct object_id *oid1, const char *prefix,
> } else {
> rewrite_with = oid2;
> }
> - oidcpy(rewrite_here, rewrite_with);
> + hashcpy(rewrite_here->hash, rewrite_with->hash);Hrm. Our coccinelle patches will want to convert this back to oidcpy(), though I see you drop them in the final patch.
However, I wonder if it points to another mismatch. Isn't the point that we _don't_ actually have "struct object_id"s here? I.e., rewrite_here and rewrite_with should actually be "const unsigned char *" that we happen to know are the_hash_algo->raw_sz?
I think the only reason they are "struct object_id" is because that's what tree_entry_extract() returns. Should we be providing another function to allow more byte-oriented access?
-Peff