git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Han-Wen Nienhuys via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Han-Wen Nienhuys <hanwenn@gmail.com>,
	Han-Wen Nienhuys <hanwen@google.com>
Subject: Re: [PATCH v2] refs.h: make all flags arguments unsigned
Date: Tue, 01 Feb 2022 21:20:59 +0100	[thread overview]
Message-ID: <220201.86ilty9vq2.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <pull.1210.v2.git.git.1643719616840.gitgitgadget@gmail.com>


On Tue, Feb 01 2022, Han-Wen Nienhuys via GitGitGadget wrote:

> From: Han-Wen Nienhuys <hanwen@google.com>
>
> As discussed in
> https://lore.kernel.org/git/xmqqbkzrkevo.fsf@gitster.g/ , we don't
> want to treat the sign bit specially, so make all flags in refs.h
> unsigned.
>
> For uniformity, rename all variables to `flags` or `unused_flags`,
> from `flag`. In a couple of shadowing cases, use `ref_flags` for
> clarity.

For what it's worth I thought the suggestion of enums in your
https://lore.kernel.org/git/xmqqbkzrkevo.fsf@gitster.g/ made more sense,
e.g. I tried this on top:
	
	diff --git a/refs.c b/refs.c
	index 5f29775def1..dc33573f064 100644
	--- a/refs.c
	+++ b/refs.c
	@@ -265,7 +265,8 @@ int ref_resolves_to_object(const char *refname,
	 }
	 
	 char *refs_resolve_refdup(struct ref_store *refs, const char *refname,
	-			  int resolve_flags, struct object_id *oid,
	+			  enum resolve_ref_flags resolve_flags,
	+			  struct object_id *oid,
	 			  unsigned int *flags)
	 {
	 	const char *result;
	@@ -276,7 +277,8 @@ char *refs_resolve_refdup(struct ref_store *refs, const char *refname,
	 	return xstrdup_or_null(result);
	 }
	 
	-char *resolve_refdup(const char *refname, unsigned int resolve_flags,
	+char *resolve_refdup(const char *refname,
	+		     enum resolve_ref_flags resolve_flags,
	 		     struct object_id *oid, unsigned int *flags)
	 {
	 	return refs_resolve_refdup(get_main_ref_store(the_repository),
	@@ -292,7 +294,8 @@ struct ref_filter {
	 	void *cb_data;
	 };
	 
	-int read_ref_full(const char *refname, unsigned int resolve_flags,
	+int read_ref_full(const char *refname,
	+		  enum resolve_ref_flags resolve_flags,
	 		  struct object_id *oid, unsigned int *flags)
	 {
	 	int ignore_errno;
	@@ -1679,7 +1682,8 @@ int refs_read_raw_ref(struct ref_store *ref_store, const char *refname,
	 }
	 
	 const char *refs_resolve_ref_unsafe(struct ref_store *refs, const char *refname,
	-				    int resolve_flags, struct object_id *oid,
	+				    enum resolve_ref_flags resolve_flags,
	+				    struct object_id *oid,
	 				    unsigned int *flags, int *failure_errno)
	 {
	 	static struct strbuf sb_refname = STRBUF_INIT;
	@@ -1779,7 +1783,8 @@ int refs_init_db(struct strbuf *err)
	 	return refs->be->init_db(refs, err);
	 }
	 
	-const char *resolve_ref_unsafe(const char *refname, int resolve_flags,
	+const char *resolve_ref_unsafe(const char *refname,
	+			       enum resolve_ref_flags resolve_flags,
	 			       struct object_id *oid, unsigned int *flags)
	 {
	 	int ignore_errno;
	diff --git a/refs.h b/refs.h
	index c5462b75807..8c7404eaf78 100644
	--- a/refs.h
	+++ b/refs.h
	@@ -64,24 +64,30 @@ struct worktree;
	  * type of failure encountered, but not necessarily one that came from
	  * a syscall. We might have faked it up.
	  */
	-#define RESOLVE_REF_READING 0x01
	-#define RESOLVE_REF_NO_RECURSE 0x02
	-#define RESOLVE_REF_ALLOW_BAD_NAME 0x04
	+enum resolve_ref_flags {
	+	RESOLVE_REF_READING = 1 << 0,
	+	RESOLVE_REF_NO_RECURSE = 1 << 1,
	+	RESOLVE_REF_ALLOW_BAD_NAME = 1 << 2,
	+};
	 
	 const char *refs_resolve_ref_unsafe(struct ref_store *refs, const char *refname,
	-				    int resolve_flags, struct object_id *oid,
	+				    enum resolve_ref_flags resolve_flags,
	+				    struct object_id *oid,
	 				    unsigned int *flags, int *failure_errno);
	 
	-const char *resolve_ref_unsafe(const char *refname, int resolve_flags,
	+const char *resolve_ref_unsafe(const char *refname,
	+			       enum resolve_ref_flags resolve_flags,
	 			       struct object_id *oid, unsigned int *flags);
	 
	 char *refs_resolve_refdup(struct ref_store *refs, const char *refname,
	-			  int resolve_flags, struct object_id *oid,
	+			  enum resolve_ref_flags resolve_flags,
	+			  struct object_id *oid,
	 			  unsigned int *flags);
	-char *resolve_refdup(const char *refname, unsigned int resolve_flags,
	+char *resolve_refdup(const char *refname,
	+		     enum resolve_ref_flags resolve_flags,
	 		     struct object_id *oid, unsigned int *flags);
	 
	-int read_ref_full(const char *refname, unsigned int resolve_flags,
	+int read_ref_full(const char *refname, enum resolve_ref_flags resolve_flags,
	 		  struct object_id *oid, unsigned int *flags);
	 int read_ref(const char *refname, struct object_id *oid);

I don't mind if this goes in, but I think doing that would make this
much easier to deal with, as it would be more obvious when working on
the code just what flag you're dealing with. Even as Junio points out
downthread of that it mostly doesn't matter in C.

See though 3f9ab7ccdea (parse-options.[ch]: consistently use "enum
parse_opt_flags", 2021-10-08) where doing it this way makes debugging
much nicer to work with.

> -		int flag;
> -		char *head_ref = resolve_refdup("HEAD", 0, NULL, &flag);
> -		if (head_ref &&
> -		    (!(flag & REF_ISSYMREF) || strcmp(head_ref, new_branch_info->path)))
> +		unsigned int flags;
> +		char *head_ref = resolve_refdup("HEAD", 0, NULL, &flags);
> +		if (head_ref && (!(flags & REF_ISSYMREF) ||
> +				 strcmp(head_ref, new_branch_info->path)))

I don't think this needs a re-roll, but FWIW I think it's much easier to
review changes like these if the changes are kept apart. E.g. this
variable renaming from the type change.

> -static int add_one_refname(const char *refname,
> -			   const struct object_id *oid,
> -			   int flag, void *cbdata)
> +static int add_one_refname(const char *refname, const struct object_id *oid,
> +			   unsigned int unused_flags, void *cbdata)

And this change not mentioned in the commit message of seemingly doing
some re-flowing of argument lists while we're at it.

The post-image is better, but better done is another step IMO.

I didn't look through the rest of the diff as you sent it, but locally
with appropriate word-diff flags to hide any formatting changes.

The post-image LGTM, but I'm also a bit "meh" on the churn just for
signed->unsigned, especially given the conflict with my in-flight
ab/no-errno-from-resolve-ref-unsafe. But it's not too bad, and if Junio
hasn't complained about it...

  reply	other threads:[~2022-02-01 20:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-31 20:15 [PATCH] refs.h: make all flags arguments unsigned Han-Wen Nienhuys via GitGitGadget
2022-02-01  2:02 ` Junio C Hamano
2022-02-01 11:47   ` Han-Wen Nienhuys
2022-02-01 18:41     ` Junio C Hamano
2022-02-01 12:46 ` [PATCH v2] " Han-Wen Nienhuys via GitGitGadget
2022-02-01 20:20   ` Ævar Arnfjörð Bjarmason [this message]
2022-02-01 23:03     ` Junio C Hamano
2022-02-03 14:29       ` Han-Wen Nienhuys
2022-02-03 17:53         ` Ævar Arnfjörð Bjarmason
2022-02-03 18:16           ` Han-Wen Nienhuys
2022-02-03 21:20             ` Ævar Arnfjörð Bjarmason
2022-02-03 18:27           ` Junio C Hamano
2022-02-03 18:33             ` Han-Wen Nienhuys
2022-02-03 19:15               ` Junio C Hamano
2022-02-03 14:26   ` [PATCH v3 0/2] " Han-Wen Nienhuys via GitGitGadget
2022-02-03 14:26     ` [PATCH v3 1/2] " Han-Wen Nienhuys via GitGitGadget
2022-02-03 14:26     ` [PATCH v3 2/2] Uniformize flag argument naming to `flags` or `unused_flags` Han-Wen Nienhuys via GitGitGadget

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=220201.86ilty9vq2.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=hanwen@google.com \
    --cc=hanwenn@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).