git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Kousik Sanagavarapu <five231003@gmail.com>
To: Andy Koppe <andy.koppe@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v3 5/7] refs: add pseudorefs array and iteration functions
Date: Tue, 6 Feb 2024 00:25:43 +0530	[thread overview]
Message-ID: <ZcEvLwp0t8-rcyGn@five231003> (raw)
In-Reply-To: <20231023221143.72489-6-andy.koppe@gmail.com>

Andy Koppe <andy.koppe@gmail.com> wrote:

> Define const array 'pseudorefs' with the names of the pseudorefs that
> are documented in gitrevisions.1, and add functions for_each_pseudoref()
> and refs_for_each_pseudoref() for iterating over them.
> 
> The functions process the pseudorefs in the same way as head_ref() and
> refs_head_ref() process HEAD, invoking an each_ref_fn callback on each
> pseudoref that exists.
> 
> This is in preparation for adding pseudorefs to log decorations.
> 
> Signed-off-by: Andy Koppe <andy.koppe@gmail.com>
> ---

[...]

> +/*
> + * List of documented pseudorefs. This needs to be kept in sync with the list
> + * in Documentation/revisions.txt.
> + */
> +static const char *const pseudorefs[] = {
> +	"FETCH_HEAD",
> +	"ORIG_HEAD",
> +	"MERGE_HEAD",
> +	"REBASE_HEAD",
> +	"CHERRY_PICK_HEAD",
> +	"REVERT_HEAD",
> +	"BISECT_HEAD",
> +	"AUTO_MERGE",
> +};
> +
>  struct ref_namespace_info ref_namespace[] = {
>  	[NAMESPACE_HEAD] = {
>  		.ref = "HEAD",
> @@ -1549,6 +1564,33 @@ int head_ref(each_ref_fn fn, void *cb_data)
>  	return refs_head_ref(get_main_ref_store(the_repository), fn, cb_data);
>  }

The first thing that popped up in my head was "Should we somehow use
is_pseudoref_syntax() instead of manually listing these?" (although I
read in this thread later that Junio was okay with the listing) but then ...

I thought I saw something similar in some other thread (which entered
the mailing list much after this patch series was submitted) ...

	https://lore.kernel.org/git/20231221170715.110565-2-karthik.188@gmail.com/T/

The whole thread is really interesting but some points that are worth to
be mentioned in this context are

	" ... Patrick's reftable work based on Han-Wen's work revealed
	the need to treat FETCH_HEAD and MERGE_HEAD as "even more
	pecurilar than pseudorefs" that need different term (tentatively
	called "special refs") ... "

So since we are introducing this array in refs.c, which acts as a "refs
API" currently

	"A lot more reasonable thing to do may be to scan the
	$GIT_DIR for files whose name satisfy refs.c:is_pseudoref_syntax()
	and list them, instead of having a hardcoded list of these special
	refs.  In addition, when reftable and other backends that can
	natively store things outside refs/ hierarchy is in use, they ought
	to know what they have so enumerating these would not be an issue
	for them without having such a hardcoded table of names."

All that said, the above mentioned thread led to a series of patches for
a different purpose than this [1] (which are currently on their way to
"master" according to the latest "What's Cooking" email on Feb 2).  The
ones that have significance w.r.t. to THIS patch series though, are

	https://lore.kernel.org/git/20240129113527.607022-2-karthik.188@gmail.com/
	https://lore.kernel.org/git/20240129113527.607022-4-karthik.188@gmail.com/

(ignoring the reftable part).

I find these to make sense HERE because using the functions introduced
THERE are much more robust when dealing with pseudorefs and can be used
HERE.

I haven't given it much thought but I think we would still end up
writing "for_each_pseudoref()", although much differently from below
(and can't use "refs_for_each_all_refs()" directly) because of how we
call this function in PATCH 7/7 when actually doing the decoration - that
is the decoration for pseudorefs is different (?)

Another approach would be I think to refactor the whole of how
decorations with refs work and somehow use "refs_for_each_all_refs()"
with its callback handling how we decorate the various refs - I need to
dig deeper :) - since the end goal is to support showing all kinds of
refs when showing the log

	$ git log -1 --clear-decorations --oneline master
	2a540e432f (ORIG_HEAD, FETCH_HEAD, upstream/master, upstream/HEAD, master) The thirteenth batch

(with color enabled)

> +int refs_for_each_pseudoref(struct ref_store *refs,
> +			    each_ref_fn fn, void *cb_data)
> +{
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(pseudorefs); i++) {
> +		struct object_id oid;
> +		int flag;
> +
> +		if (refs_resolve_ref_unsafe(refs, pseudorefs[i],
> +					    RESOLVE_REF_READING, &oid, &flag)) {
> +			int ret = fn(pseudorefs[i], &oid, flag, cb_data);
> +
> +			if (ret)
> +				return ret;
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +int for_each_pseudoref(each_ref_fn fn, void *cb_data)
> +{
> +	return refs_for_each_pseudoref(get_main_ref_store(the_repository),
> +				       fn, cb_data);
> +}
> +
>  struct ref_iterator *refs_ref_iterator_begin(
>  		struct ref_store *refs,
>  		const char *prefix,
> diff --git a/refs.h b/refs.h
> index 23211a5ea1..7b55cced31 100644
> --- a/refs.h
> +++ b/refs.h
> @@ -320,6 +320,8 @@ typedef int each_repo_ref_fn(struct repository *r,
>   */
>  int refs_head_ref(struct ref_store *refs,
>  		  each_ref_fn fn, void *cb_data);
> +int refs_for_each_pseudoref(struct ref_store *refs,
> +			    each_ref_fn fn, void *cb_data);
>  int refs_for_each_ref(struct ref_store *refs,
>  		      each_ref_fn fn, void *cb_data);
>  int refs_for_each_ref_in(struct ref_store *refs, const char *prefix,
> @@ -334,6 +336,9 @@ int refs_for_each_remote_ref(struct ref_store *refs,
>  /* just iterates the head ref. */
>  int head_ref(each_ref_fn fn, void *cb_data);
>  
> +/* iterates pseudorefs. */
> +int for_each_pseudoref(each_ref_fn fn, void *cb_data);
> +
>  /* iterates all refs. */
>  int for_each_ref(each_ref_fn fn, void *cb_data);
>  
> -- 
> 2.42.GIT

So yeah, I just wanted to point out the above things as we would need to
refactor this commit and the commits following this - patches 6/7 and 7/7.

Thanks

[1]: https://lore.kernel.org/git/20240129113527.607022-1-karthik.188@gmail.com/


  parent reply	other threads:[~2024-02-05 18:55 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-03 20:54 [PATCH] decorate: add color.decorate.symbols config option Andy Koppe
2023-10-19 19:39 ` [PATCH 0/7] log: decorate pseudorefs and other refs Andy Koppe
2023-10-22  0:13   ` Junio C Hamano
2023-10-22 21:49     ` Andy Koppe
2023-10-23  0:20       ` Junio C Hamano
2023-10-23 22:15         ` Andy Koppe
2023-10-22 21:44   ` [PATCH v2 0/6] " Andy Koppe
2023-10-22 21:44     ` [PATCH v2 1/6] config: restructure color.decorate documentation Andy Koppe
2023-10-22 21:44     ` [PATCH v2 2/6] log: add color.decorate.symbol config variable Andy Koppe
2023-10-22 21:44     ` [PATCH v2 3/6] log: add color.decorate.ref " Andy Koppe
2023-10-22 21:44     ` [PATCH v2 4/6] refs: add pseudorefs array and iteration functions Andy Koppe
2023-10-22 21:44     ` [PATCH v2 5/6] refs: exempt pseudorefs from pattern prefixing Andy Koppe
2023-10-22 21:44     ` [PATCH v2 6/6] log: add color.decorate.pseudoref config variable Andy Koppe
2023-10-23 22:11     ` [PATCH v3 0/7] log: decorate pseudorefs and other refs Andy Koppe
2023-10-23 22:11       ` [PATCH v3 1/7] config: restructure color.decorate documentation Andy Koppe
2023-10-23 22:11       ` [PATCH v3 2/7] log: use designated inits for decoration_colors Andy Koppe
2023-10-23 22:11       ` [PATCH v3 3/7] log: add color.decorate.symbol config variable Andy Koppe
2023-10-23 22:11       ` [PATCH v3 4/7] log: add color.decorate.ref " Andy Koppe
2023-10-23 22:11       ` [PATCH v3 5/7] refs: add pseudorefs array and iteration functions Andy Koppe
2023-10-24  0:08         ` Junio C Hamano
2024-02-05 18:55         ` Kousik Sanagavarapu [this message]
2024-02-07 22:02           ` Junio C Hamano
2023-10-23 22:11       ` [PATCH v3 6/7] refs: exempt pseudorefs from pattern prefixing Andy Koppe
2023-10-23 22:11       ` [PATCH v3 7/7] log: add color.decorate.pseudoref config variable Andy Koppe
2023-10-19 19:39 ` [PATCH 1/7] config: restructure color.decorate documentation Andy Koppe
2023-10-19 19:39 ` [PATCH 2/7] log: use designated inits for decoration_colors Andy Koppe
2023-10-19 19:39 ` [PATCH 3/7] log: add color.decorate.symbol config option Andy Koppe
2023-10-19 19:39 ` [PATCH 4/7] refs: separate decoration type from default filter Andy Koppe
2023-10-19 19:39 ` [PATCH 5/7] log: add color.decorate.ref option for other refs Andy Koppe
2023-10-19 19:39 ` [PATCH 6/7] refs: exempt pseudoref patterns from prefixing Andy Koppe
2023-10-19 19:39 ` [PATCH 7/7] log: show pseudorefs in decorations Andy Koppe

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=ZcEvLwp0t8-rcyGn@five231003 \
    --to=five231003@gmail.com \
    --cc=andy.koppe@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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).