git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: nbelakovski@gmail.com
Cc: git@vger.kernel.org, rafa.almas@gmail.com, gitster@pobox.com,
	avarab@gmail.com
Subject: Re: [PATCH v4 1/3] ref-filter: add worktreepath atom
Date: Thu, 3 Jan 2019 00:40:43 -0500	[thread overview]
Message-ID: <20190103054043.GG20047@sigill.intra.peff.net> (raw)
In-Reply-To: <20181224084756.49952-2-nbelakovski@gmail.com>

On Mon, Dec 24, 2018 at 12:47:54AM -0800, nbelakovski@gmail.com wrote:

> [...]

Thanks for keeping with this.  I think we're getting quite close, though
I did find a few small-ish issues.

> @@ -34,6 +36,8 @@ static struct ref_msg {
>  	"ahead %d, behind %d"
>  };
>  
> +static struct worktree **worktrees;
> +

Maybe define this near "struct hashmap ref_to_worktree_map" so it's
more obvious that the two are related?

> @@ -75,6 +79,11 @@ static struct expand_data {
>  	struct object_info info;
>  } oi, oi_deref;
>  
> +struct ref_to_worktree_entry {
> +    struct hashmap_entry ent; /* must be the first member! */
> +    struct worktree *wt; /* key is wt->head_ref */
> +};

Indent with spaces?

> -static int used_atom_cnt, need_tagged, need_symref;
> +static int used_atom_cnt, need_tagged, need_symref, has_worktree;
> +static struct hashmap ref_to_worktree_map;

Makes sense. I thought at first has_worktree was a flag that we might
care about between parsing and formatting, but it's really just a flag
to say "we lazy-loaded the worktree list".

> +static int worktree_hashmap_cmpfnc(const void *unused_lookupdata, const void *existing_hashmap_entry_to_test,
> +				   const void *unused_key, const void *keydata_aka_refname)
> +{
> +	const struct ref_to_worktree_entry *e = existing_hashmap_entry_to_test;
> +	return strcmp(e->wt->head_ref, keydata_aka_refname);
> +}

So from the discussion in the cover letter, this needs to be more like:

  static int worktree_hashmap_cmpfnc(const void *unused_lookupdata,
                                     const void *ve1, const void *ve2,
				     const void *keydata_aka_refname)
  {
	const struct ref_to_worktree_entry *e1 = ve1, *e2 = ve2;
	return strcmp(e1->wt->head_ref, keydata_aka_refname ?
		                        keydata_aka_refname :
					e2->wt->head_ref);
  }

> +static int worktree_atom_parser(const struct ref_format *format,
> +				struct used_atom *atom,
> +				const char *arg,
> +				struct strbuf *unused_err)
> +{
> +	int i;
> +	if (has_worktree)
> +		return 0;

Minor style nit, but please put a space between the declarations and the
start of the code (not strictly necessary for a short function which has
no other linebreaks, like the cmpfunc above, but here I think it's
confusing not to).

> +	worktrees = get_worktrees(0);
> +
> +	hashmap_init(&ref_to_worktree_map, worktree_hashmap_cmpfnc, NULL, 0);
> +
> +	for (i = 0; worktrees[i]; i++) {
> +		if (worktrees[i]->head_ref) {
> +			struct ref_to_worktree_entry *entry;
> +			entry = xmalloc(sizeof(*entry));
> +			entry->wt = worktrees[i];
> +			hashmap_entry_init(entry, strhash(worktrees[i]->head_ref));
> +
> +			hashmap_add(&ref_to_worktree_map, entry);
> +		}
> +	}

Makes sense to load the map.

> +static const char *get_worktree_path(const struct used_atom *atom, const struct ref_array_item *ref)
> +{
> +	struct strbuf val = STRBUF_INIT;
> +	struct hashmap_entry entry;
> +	struct ref_to_worktree_entry *lookup_result;
> +
> +	hashmap_entry_init(&entry, strhash(ref->refname));
> +	lookup_result = hashmap_get(&ref_to_worktree_map, &entry, ref->refname);
> +
> +	strbuf_addstr(&val, lookup_result ? lookup_result->wt->path : "");
> +
> +	return strbuf_detach(&val, NULL);
> +}

And that makes sense to look up an item in it. Good.

Adding an empty string to a strbuf is a noop, so that part might more
clearly be written as just:

  if (lookup_result)
	strbuf_addstr(&val, lookup_result->wt->path);

We return a "const char *" here, but the result is always allocated. Do
we leak the result? Or should this return a "char *"?

I think there are a lot of other atoms that leak currently, but that is
being fixed in another topic that is currently in pu.

> @@ -2020,6 +2085,11 @@ void ref_array_clear(struct ref_array *array)
>  		free_array_item(array->items[i]);
>  	FREE_AND_NULL(array->items);
>  	array->nr = array->alloc = 0;
> +	if (has_worktree)
> +	{
> +		hashmap_free(&ref_to_worktree_map, 1);
> +		free_worktrees(worktrees);
> +	}

Here we free everything, but we don't unset has_worktree. So anybody
trying to format more refs afterward would see our freed worktree list.

We probably want:

  has_worktree = 0;

here. Or simpler still, I think get_worktrees() will always return a
non-NULL list (even if it is empty). So you could just drop has_worktree
entirely, and use:

  if (worktrees)
	return; /* already loaded */;

in the loading function, and:

  free_worktrees(worktrees);
  worktrees = NULL;

here.

> +test_expect_success '"add" a worktree' '
> +	mkdir worktree_dir &&
> +	git worktree add -b master_worktree worktree_dir master
> +'
> +
> +test_expect_success 'validate worktree atom' '
> +	{
> +	echo master: $PWD &&
> +	echo master_worktree: $PWD/worktree_dir &&
> +	echo side: not checked out
> +	} > expect &&

Minor style nit: use "} >expect" without the extra space.

This checks the actual directories. Good. I can never remember the rules
for when to use $PWD versus $(pwd) on Windows. We may run afoul of the
distinction here.

-Peff

  reply	other threads:[~2019-01-03  5:40 UTC|newest]

Thread overview: 125+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <"<CAC05386q2iGoiJ_fRgwoOTF23exEN2D1+oh4VjajEvYQ58O1TQ@mail.gmail.com>
2018-09-27 15:13 ` [PATCH] branch: colorize branches checked out in a linked working tree the same way as the current branch is colorized Nickolai Belakovski
2018-09-27 15:33   ` Ævar Arnfjörð Bjarmason
2018-09-27 17:46     ` Nickolai Belakovski
     [not found]     ` <CAC05387S9P+w8yqqcjkQDnURYSgQmqtukxS4KvqJu-kDA+_o0g@mail.gmail.com>
2018-09-27 17:59       ` Ævar Arnfjörð Bjarmason
2018-10-02 20:41         ` Johannes Schindelin
2018-09-27 17:58   ` Duy Nguyen
2018-09-27 18:17   ` Jeff King
2018-09-27 18:39     ` Nickolai Belakovski
2018-09-27 18:51       ` Jeff King
2018-09-27 19:28     ` Rafael Ascensão
2018-09-27 19:35       ` Jeff King
2018-09-27 19:41         ` Jeff King
2018-09-27 21:22           ` Junio C Hamano
2018-09-28  1:05             ` Jeff King
2018-09-28  1:28               ` Junio C Hamano
2018-09-27 21:35         ` Rafael Ascensão
2018-09-28  1:07           ` Jeff King
2018-09-27 20:02       ` Ævar Arnfjörð Bjarmason
2018-09-27 20:16         ` Nickolai Belakovski
2018-09-27 20:40           ` Rafael Ascensão
2018-11-11 23:58             ` [PATCH v2 0/2] refactoring branch colorization to ref-filter nbelakovski
2018-11-11 23:58               ` [PATCH v2 1/2] ref-filter: add worktree atom nbelakovski
2018-11-12 10:11                 ` Junio C Hamano
2018-11-12 12:22                   ` Jeff King
2018-11-13  1:38                     ` Junio C Hamano
2018-11-21 14:05                       ` Nickolai Belakovski
2018-11-21 14:08                         ` Jeff King
2018-11-12 12:23                 ` Jeff King
2018-11-11 23:58               ` [PATCH v2 2/2] branch: Mark and colorize a branch differently if it is checked out in a linked worktree nbelakovski
2018-11-12 10:20                 ` Junio C Hamano
2018-11-12 12:14                   ` Jeff King
2018-11-12 18:07                     ` Rafael Ascensão
2018-11-13  1:45                       ` Junio C Hamano
2018-11-13 14:49                       ` Jeff King
2018-11-21 14:07                         ` Nickolai Belakovski
2018-12-16 21:57               ` [PATCH v3 0/3] nbelakovski
2018-12-16 21:57                 ` [PATCH v3 1/3] ref-filter: add worktreepath atom nbelakovski
2018-12-18 17:22                   ` Jeff King
2018-12-20  7:09                     ` Nickolai Belakovski
2018-12-20 14:59                       ` Jeff King
2018-12-24  8:47                         ` [PATCH v4 0/3] nbelakovski
2018-12-24  8:47                           ` [PATCH v4 1/3] ref-filter: add worktreepath atom nbelakovski
2019-01-03  5:40                             ` Jeff King [this message]
2019-01-03  9:31                               ` Eric Sunshine
2018-12-24  8:47                           ` [PATCH v4 2/3] branch: Mark and color a branch differently if it is checked out in a linked worktree nbelakovski
2018-12-24  8:47                           ` [PATCH v4 3/3] branch: Add an extra verbose output displaying worktree path for refs " nbelakovski
2019-01-03  5:42                             ` Jeff King
2019-01-03  5:22                           ` [PATCH v4 0/3] Jeff King
2018-12-16 21:57                 ` [PATCH v3 2/3] branch: Mark and color a branch differently if it is checked out in a linked worktree nbelakovski
2018-12-16 21:57                 ` [PATCH v3 3/3] branch: Add an extra verbose output displaying worktree path for refs " nbelakovski
2018-12-18 17:25                 ` [PATCH v3 0/3] Jeff King
2019-01-06  0:26   ` [PATCH v5 0/3] nbelakovski
2019-01-06  0:26     ` [PATCH v5 1/3] ref-filter: add worktreepath atom nbelakovski
2019-01-07 18:20       ` Junio C Hamano
2019-01-18 22:17         ` Nickolai Belakovski
2019-01-18 22:20           ` Nickolai Belakovski
2019-01-06  0:26     ` [PATCH v5 2/3] branch: Mark and color a branch differently if it is checked out in a linked worktree nbelakovski
2019-01-07 19:04       ` Junio C Hamano
2019-01-10 21:42         ` Philip Oakley
2019-01-13  1:41           ` Nickolai Belakovski
2019-01-14 18:18             ` Junio C Hamano
2019-01-18 22:18               ` Nickolai Belakovski
2019-01-06  0:26     ` [PATCH v5 3/3] branch: Add an extra verbose output displaying worktree path for refs " nbelakovski
2019-01-07 19:09       ` Junio C Hamano
2019-01-22 23:22   ` [PATCH v6 0/3] nbelakovski
2019-01-22 23:22     ` [PATCH v6 1/3] ref-filter: add worktreepath atom nbelakovski
2019-01-23 18:57       ` Junio C Hamano
2019-01-23 23:34         ` Nickolai Belakovski
2019-01-24 18:26           ` Junio C Hamano
2019-01-24 18:32             ` Jeff King
2019-01-24 19:27               ` Junio C Hamano
2019-01-24 19:34                 ` Jeff King
2019-01-24 19:30               ` Junio C Hamano
2019-01-24 21:26                 ` Jeff King
2019-01-31 20:53                   ` Nickolai Belakovski
2019-01-31 23:21                     ` Jeff King
2019-01-31 21:42                   ` Junio C Hamano
2019-01-31 23:20                     ` Jeff King
2019-01-22 23:23     ` [PATCH v6 2/3] branch: Mark and color a branch differently if it is checked out in a linked worktree nbelakovski
2019-01-22 23:23     ` [PATCH v6 3/3] branch: Add an extra verbose output displaying worktree path for refs " nbelakovski
2019-02-01 22:04   ` [PATCH v7 0/3] nbelakovski
2019-02-01 22:28     ` Junio C Hamano
2019-02-01 23:31       ` Nickolai Belakovski
2019-02-01 22:04   ` [PATCH v7 1/3] ref-filter: add worktreepath atom nbelakovski
2019-02-01 22:20     ` Eric Sunshine
2019-02-01 22:41       ` Nickolai Belakovski
2019-02-04 18:14         ` Junio C Hamano
2019-02-18 10:09           ` Nickolai Belakovski
2019-02-01 22:31     ` Junio C Hamano
2019-02-01 22:04   ` [PATCH v7 2/3] branch: Mark and color a branch differently if it is checked out in a linked worktree nbelakovski
2019-02-01 22:34     ` Junio C Hamano
2019-02-01 23:12       ` Nickolai Belakovski
2019-02-04 18:18         ` Junio C Hamano
2019-02-01 22:04   ` [PATCH v7 3/3] branch: Add an extra verbose output displaying worktree path for refs " nbelakovski
2019-02-01 22:27     ` Eric Sunshine
2019-02-01 22:45       ` Nickolai Belakovski
2019-02-01 22:53     ` Junio C Hamano
2019-02-01 23:06       ` Nickolai Belakovski
2019-02-02  1:22         ` [RFC] Sample of test for git branch -vv nbelakovski
2019-02-19  8:31   ` [PATCH v8 0/3] nbelakovski
2019-02-19  8:31     ` [PATCH v8 1/3] ref-filter: add worktreepath atom nbelakovski
2019-02-19  8:31     ` [PATCH v8 2/3] branch: update output to include worktree info nbelakovski
2019-02-21 12:44       ` Jeff King
2019-03-14  5:45         ` Nickolai Belakovski
2019-02-19  8:31     ` [PATCH v8 3/3] branch: add worktree info on verbose output nbelakovski
2019-02-21 12:59       ` Jeff King
2019-03-14  5:58         ` Nickolai Belakovski
2019-03-18  2:12           ` Junio C Hamano
2019-02-21 12:36     ` [PATCH v8 0/3] Jeff King
2019-03-14  6:10       ` Nickolai Belakovski
2019-03-16  1:38   ` [PATCH v9 0/3] nbelakovski
2019-03-16  1:38     ` [PATCH v9 1/3] ref-filter: add worktreepath atom nbelakovski
2019-03-16  1:38     ` [PATCH v9 2/3] branch: update output to include worktree info nbelakovski
2019-03-16  1:38     ` [PATCH v9 3/3] branch: add worktree info on verbose output nbelakovski
2019-03-18 12:10       ` SZEDER Gábor
2019-03-18  5:30     ` [PATCH v9 0/3] Junio C Hamano
2019-04-29  5:19   ` [PATCH v10 0/3] nbelakovski
2019-04-29  5:19     ` [PATCH v10 1/3] ref-filter: add worktreepath atom nbelakovski
2019-04-29  5:19     ` [PATCH v10 2/3] branch: update output to include worktree info nbelakovski
2019-04-29  5:19     ` [PATCH v10 3/3] branch: add worktree info on verbose output nbelakovski
2019-04-29 14:12     ` [PATCH v10 0/3] SZEDER Gábor
2019-04-29 19:27       ` Nickolai Belakovski
2019-04-29 20:57     ` Johannes Schindelin
2019-04-29 21:33       ` Nickolai Belakovski
     [not found]       ` <CAC05385Mc7pqiCd5mb+1c4WM+v7K=h=GMHuvkw9xizhRFJXXBA@mail.gmail.com>
2019-04-30 21:46         ` Johannes Schindelin

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=20190103054043.GG20047@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=nbelakovski@gmail.com \
    --cc=rafa.almas@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).