git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Stefan Beller <sbeller@google.com>
Cc: git@vger.kernel.org, jens.lehmann@web.de, hvoigt@hvoigt.net
Subject: Re: [PATCH 1/4] submodule: implement `module_list` as a builtin helper
Date: Fri, 07 Aug 2015 12:53:16 -0700	[thread overview]
Message-ID: <xmqqwpx6yixf.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1438733070-15805-1-git-send-email-sbeller@google.com> (Stefan Beller's message of "Tue, 4 Aug 2015 17:04:29 -0700")

Stefan Beller <sbeller@google.com> writes:

> diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
> new file mode 100644
> index 0000000..cb18ddf
> --- /dev/null
> +++ b/builtin/submodule--helper.c
> @@ -0,0 +1,111 @@
> + ...
> +static char *ps_matched;
> +static const struct cache_entry **ce_entries;
> +static int ce_alloc, ce_used;
> +static struct pathspec pathspec;
> +static const char *alternative_path;

These are OK for now to be global variables, but in the longer run,
I think you would need to introduce a struct or two that group the
relevant pieces and passed around the callchain.  For example, a
caller calling into module_list_compute() would want to pass a
pointer to a struct that has ce_entries[] and ps_matched to receive
the result.  pathspec and alternative_path would want to be a
function-scope auto variable in module_list, I would think.

> +static void module_list_compute(int argc, const char **argv,
> +				const char *prefix,
> +				struct pathspec *pathspec)
> +{
> +	int i;
> +	char *max_prefix;
> +	int max_prefix_len;
> +	parse_pathspec(pathspec, 0,
> +		       PATHSPEC_PREFER_FULL |
> +		       PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP,
> +		       prefix, argv);
> +
> +	/* Find common prefix for all pathspec's */
> +	max_prefix = common_prefix(pathspec);
> +	max_prefix_len = max_prefix ? strlen(max_prefix) : 0;
> +
> +	if (pathspec->nr)
> +		ps_matched = xcalloc(1, pathspec->nr);
> +
> +
> +	if (read_cache() < 0)
> +		die("index file corrupt");

Again, this is OK for now, but I suspect you would eventually want
to return an error and have the caller react to it.

> +static int module_list(int argc, const char **argv, const char *prefix)
> +{
> +...
> +	for (i = 0; i < ce_used; i++) {
> +		const struct cache_entry *ce = ce_entries[i];
> +
> +		if (string_list_has_string(&already_printed, ce->name))
> +			continue;
> +
> +		if (ce_stage(ce)) {
> +			printf("%06o %s U\t", ce->ce_mode, sha1_to_hex(null_sha1));
> +		} else {
> +			printf("%06o %s %d\t", ce->ce_mode, sha1_to_hex(ce->sha1), ce_stage(ce));
> +		}
> +
> +		utf8_fprintf(stdout, "%s\n", ce->name);
> +
> +		string_list_insert(&already_printed, ce->name);

This looks a wasteful use of string-list.

When we iterate over the in-core index, or a subset obtained from
the in-core index without reordering, the standard technique to
handle entries for the same path only once is to handle one (while
remembering what it is) and then skip the ones that follow with the
same name, with a loop like this:

	i = 0;
        while (i < ce_used) {
        	ce = ce_entries[i++];
		use that ce;
                while (i < ce_used && !strcmp(ce->ce_name, ce_entries[i]->ce_name))
			i++; /* skip entries with the same name */
	}

Take advantage of the fact that the entries are still sorted.

      parent reply	other threads:[~2015-08-07 19:53 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-05  0:04 [PATCH 1/4] submodule: implement `module_list` as a builtin helper Stefan Beller
2015-08-05  0:04 ` [PATCH 2/4] submodule: implement `module_name` " Stefan Beller
2015-08-05  0:05   ` Stefan Beller
2015-08-05  0:58   ` Eric Sunshine
2015-08-05 16:29     ` Stefan Beller
2015-08-05 19:06   ` Jens Lehmann
2015-08-05 19:55     ` Stefan Beller
2015-08-05 21:08       ` [PATCH] " Stefan Beller
2015-08-06 19:49         ` Jens Lehmann
2015-08-06 21:38           ` Stefan Beller
2015-08-07 20:03             ` Junio C Hamano
2015-08-07 20:54               ` Stefan Beller
2015-08-07 20:17           ` Junio C Hamano
2015-08-07 20:49             ` Stefan Beller
2015-08-07 21:14               ` Junio C Hamano
2015-08-07 21:21                 ` Stefan Beller
2015-08-07 21:32                   ` Junio C Hamano
2015-08-07 22:04                     ` Stefan Beller
2015-08-07 22:18                       ` Junio C Hamano
2015-08-07 23:12                         ` Stefan Beller
2015-08-07 22:42                   ` Junio C Hamano
2015-08-07 23:19                     ` Stefan Beller
2015-08-08  0:21                       ` Junio C Hamano
2015-08-08  6:20                         ` Junio C Hamano
2015-08-10 17:03                           ` Stefan Beller
2015-08-05 18:31 ` [PATCH 1/4] submodule: implement `module_list` " Jens Lehmann
2015-08-07 19:53 ` Junio C Hamano [this message]

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

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

  git send-email \
    --in-reply-to=xmqqwpx6yixf.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=hvoigt@hvoigt.net \
    --cc=jens.lehmann@web.de \
    --cc=sbeller@google.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.
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 NNTP newsgroup(s).