From: Junio C Hamano <gitster@pobox.com>
To: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Cc: git@vger.kernel.org, git@drmicha.warpmail.net
Subject: Re: [PATCH 04/16] list-files: add tag to each entry, filter duplicate tags
Date: Thu, 12 Mar 2015 14:48:51 -0700 [thread overview]
Message-ID: <xmqqk2yl28fw.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1425896314-10941-5-git-send-email-pclouds@gmail.com> ("Nguyễn Thái Ngọc Duy"'s message of "Mon, 9 Mar 2015 17:18:22 +0700")
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> All entry strings start with two-letter tag and a space. If all
> entries have the same tags, tags are not displayed.
>
> The outcome before and after this patch is the same. But it will be
> useful in future when there are more than one type of entry.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> builtin/list-files.c | 40 ++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/list-files.c b/builtin/list-files.c
> index c444a53..18af65c 100644
> --- a/builtin/list-files.c
> +++ b/builtin/list-files.c
> @@ -18,12 +18,16 @@ struct option ls_options[] = {
> OPT_END()
> };
>
> -static void add_one(struct string_list *result, const char *name)
> +static void add_one(struct string_list *result, const char *name,
> + const char *tag)
> {
> struct strbuf sb = STRBUF_INIT;
> struct string_list_item *item;
>
> quote_path_relative(name, prefix_length ? prefix : NULL, &sb);
> + strbuf_insert(&sb, 0, " ", 3);
> + sb.buf[0] = tag[0];
> + sb.buf[1] = tag[1];
> item = string_list_append(result, strbuf_detach(&sb, NULL));
> item->util = (char *)name;
> }
> @@ -42,7 +46,38 @@ static void populate_cached_entries(struct string_list *result,
> S_ISGITLINK(ce->ce_mode)))
> continue;
>
> - add_one(result, ce->name);
> + add_one(result, ce->name, " ");
> + }
> +}
> +
> +static void cleanup_tags(struct string_list *result)
> +{
> + int i, same_1 = 1, same_2 = 1, pos, len;
> +
> + for (i = 1; i < result->nr && (same_1 || same_2); i++) {
> + const char *s0 = result->items[i - 1].string;
> + const char *s1 = result->items[i].string;
> +
> + same_1 = same_1 && s0[0] == s1[0];
> + same_2 = same_2 && s0[1] == s1[1];
> + }
> +
> + if (same_1 && same_2) {
> + pos = 0;
> + len = 3;
> + } else if (same_1) {
> + pos = 0;
> + len = 1;
> + } else if (same_2) {
> + pos = 1;
> + len = 1;
> + } else
> + return;
> +
> + for (i = 0; i < result->nr; i++) {
> + char *s = result->items[i].string;
> + int length = strlen(s);
> + memmove(s + pos, s + pos + len, length - len + 1);
> }
> }
Hmm, I wonder if a different implementation strategy would produce a
code that is better for longer term maintenance and readability.
For example, how much pain would be involved if we later find that
we would want three "tag" letters per entry and wanted to add
support for that third tag by modifying this code?
Instead of half-formatted result in item->string and then inspect
and update the already formatted string at the textual level, why
not invert the keys and values of the table and arrange things this
way instead:
* the "table" is expressed as a string-list, as this series does;
* the keys to the table, item->string, is the original pathname;
* the values in the table, item->util, is a pointer to a structure
that allows implementation of list-files a more meaningful access
to the information (as opposed to "the first column of formatted
text output means X, the second column means Y"), perhaps like
struct list_item {
enum {
LS_IS_FILE, LS_IS_DIRECTORY, LS_IS_SYMLINK, LS_IS_SUBMODULE
} kind;
unsigned changed_from_index:1,
changed_from_HEAD:1;
struct cache_time mtime;
};
* Internal processing is done to the value found in item->util, and
the textual output is created by formatting what is in the
*((struct list_item *)item->util) at the output phase.
A hypothetical "we need more tags" case would then involve adding a
new field (could be a bitfield "breaks_build:1") to the list_item
structure with a reasonable default, keeping the existing codepath
that does not care about the new field intact and updating only the
output phase, which would be a lot less painful, no?
> @@ -93,6 +128,7 @@ int cmd_list_files(int argc, const char **argv, const char *cmd_prefix)
> &pathspec, NULL, NULL);
>
> populate_cached_entries(&result, &the_index);
> + cleanup_tags(&result);
> display(&result);
> string_list_clear(&result, 0);
> return 0;
next prev parent reply other threads:[~2015-03-12 21:49 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-09 10:18 [PATCH 00/16] nd/list-files redesign Nguyễn Thái Ngọc Duy
2015-03-09 10:18 ` [PATCH 01/16] list-files: command skeleton Nguyễn Thái Ngọc Duy
2015-03-12 21:02 ` Junio C Hamano
2015-03-09 10:18 ` [PATCH 02/16] list-files: make :(glob) pathspec default Nguyễn Thái Ngọc Duy
2015-03-12 21:10 ` Junio C Hamano
2015-03-14 11:21 ` Duy Nguyen
2015-03-09 10:18 ` [PATCH 03/16] list-files: show paths relative to cwd Nguyễn Thái Ngọc Duy
2015-03-12 21:20 ` Junio C Hamano
2015-03-12 21:28 ` Junio C Hamano
2015-03-14 11:25 ` Duy Nguyen
2015-03-15 21:16 ` Junio C Hamano
2015-03-15 23:41 ` Duy Nguyen
2015-03-09 10:18 ` [PATCH 04/16] list-files: add tag to each entry, filter duplicate tags Nguyễn Thái Ngọc Duy
2015-03-12 21:48 ` Junio C Hamano [this message]
2015-03-09 10:18 ` [PATCH 05/16] list-files: add --[no-]column, -C and -1 Nguyễn Thái Ngọc Duy
2015-03-09 10:18 ` [PATCH 06/16] list-files: add --max-depth and -R Nguyễn Thái Ngọc Duy
2015-03-09 10:18 ` [PATCH 07/16] list-files: show directories as well as files Nguyễn Thái Ngọc Duy
2015-03-10 6:23 ` Eric Sunshine
2015-03-10 6:39 ` Duy Nguyen
2015-03-09 10:18 ` [PATCH 08/16] list-files: add --color Nguyễn Thái Ngọc Duy
2015-03-09 10:18 ` [PATCH 09/16] list-files: add -F/--classify Nguyễn Thái Ngọc Duy
2015-03-09 10:18 ` [PATCH 10/16] list-files: new indicator '&' for submodules when -F is used Nguyễn Thái Ngọc Duy
2015-03-09 10:18 ` [PATCH 11/16] list-files: add --cached and --others Nguyễn Thái Ngọc Duy
2015-03-09 10:18 ` [PATCH 12/16] list-files: add --ignored Nguyễn Thái Ngọc Duy
2015-03-09 10:18 ` [PATCH 13/16] list-files: add --unmerged Nguyễn Thái Ngọc Duy
2015-03-09 10:18 ` [PATCH 14/16] list-files: add file modification options -[admADM] Nguyễn Thái Ngọc Duy
2015-03-09 10:18 ` [PATCH 15/16] list-files: delete redundant cached entries Nguyễn Thái Ngọc Duy
2015-03-10 6:28 ` Eric Sunshine
2015-03-09 10:18 ` [PATCH 16/16] list-files: make alias 'ls' default to 'list-files' Nguyễn Thái Ngọc Duy
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=xmqqk2yl28fw.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=pclouds@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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.