From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 3AFA61F852 for ; Tue, 1 Feb 2022 18:59:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242108AbiBAS7D (ORCPT ); Tue, 1 Feb 2022 13:59:03 -0500 Received: from pb-smtp21.pobox.com ([173.228.157.53]:53856 "EHLO pb-smtp21.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242188AbiBAS7B (ORCPT ); Tue, 1 Feb 2022 13:59:01 -0500 Received: from pb-smtp21.pobox.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 9DB2F1740C0; Tue, 1 Feb 2022 13:59:00 -0500 (EST) (envelope-from junio@pobox.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=sasl; bh=OI8ttV+2B6qC YEsXPuZ7xXyDGAhHQUD6TE2uUK3vuys=; b=x8QB6DOsAU0IwU7i3iFFXmDdDnAx QHPC0kHXUOZisNU30e5Fcqb/7pW6qurvP5GfCrDu8uAvCKhrJuovLWgWaKb+Mwz+ l0hSRnZ7reLYugBqDLJkNZldGfrKfczOtZAaL3QMtxlKxMQ7kcMohT45z3yab3VM gYg7hYU2aw1TeJM= Received: from pb-smtp21.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 94C0F1740BF; Tue, 1 Feb 2022 13:59:00 -0500 (EST) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [104.133.2.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp21.pobox.com (Postfix) with ESMTPSA id 0DC0E1740BE; Tue, 1 Feb 2022 13:58:58 -0500 (EST) (envelope-from junio@pobox.com) From: Junio C Hamano To: =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason Cc: git@vger.kernel.org, Han Xin , Jiang Xin , =?utf-8?Q?Ren=C3=A9?= Scharfe , Derrick Stolee Subject: Re: [PATCH 04/10] object-file API: have write_object_file() take "enum object_type" References: Date: Tue, 01 Feb 2022 10:58:56 -0800 In-Reply-To: (=?utf-8?B?IsOGdmFyIEFybmZqw7Zyw7A=?= Bjarmason"'s message of "Tue, 1 Feb 2022 15:53:06 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Pobox-Relay-ID: 02B748FA-8391-11EC-A245-CBA7845BAAA9-77302942!pb-smtp21.pobox.com Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org =C3=86var Arnfj=C3=B6r=C3=B0 Bjarmason writes: > Change the write_object_file() function to take an "enum object_type" > instead of a "const char *type". Its callers either passed > {commit,tree,blob,tag}_type and can pass the corresponding OBJ_* type > instead, or were hardcoding strings like "blob". > > This avoids the back & forth fragility where the callers of > write_object_file() would have the enum type, and convert it > themselves via type_name(). We do have to now do that conversion > ourselves before calling write_object_file_prepare(), but those > codepaths will be similarly adjusted in subsequent commits. Up to this point, the series makes sense to me (I didn't check for calls that were left uncoverted by mistake, or new callers that were added on other topics---the compiler should flag them all).