From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Teng Long <dyroneteng@gmail.com>
Cc: git@vger.kernel.org, tenglong.tl@alibaba-inc.com, me@ttaylorr.com
Subject: Re: [RFC PATCH 4/6] ls-tree: improving cohension in the print code
Date: Thu, 17 Nov 2022 14:53:24 +0100 [thread overview]
Message-ID: <221117.86fsehisrw.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <20221117113023.65865-5-tenglong.tl@alibaba-inc.com>
On Thu, Nov 17 2022, Teng Long wrote:
> From: Teng Long <dyroneteng@gmail.com>
>
> We use 'show_tree_long()' and 'show_tree_default()' to print entries
> when we want the output in 'default' or 'default long' formats.
>
> Function 'show_tree_common_default_long()' prints the "path" field as
> the last part of output, the previous part which separately implements
> in 'show_tree_long()' and 'show_tree_default()'.
>
> We can package the separate implementation together by the extension of
> "size_text" in struct "show_tree_data". By improving the cohesion in
> these two locations, some benefits such as uniform processing of the
> output can be achieved in future.
>
> Signed-off-by: Teng Long <dyroneteng@gmail.com>
> ---
> builtin/ls-tree.c | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/builtin/ls-tree.c b/builtin/ls-tree.c
> index afb65af4280..7661170f7ca 100644
> --- a/builtin/ls-tree.c
> +++ b/builtin/ls-tree.c
> @@ -30,6 +30,7 @@ struct show_tree_data {
> const struct object_id *oid;
> const char *pathname;
> struct strbuf *base;
> + char *size_text;
> };
>
> static const char * const ls_tree_usage[] = {
> @@ -186,6 +187,7 @@ static int show_tree_common(struct show_tree_data *data, int *recurse,
> data->oid = oid;
> data->pathname = pathname;
> data->base = base;
> + data->size_text = NULL;
>
> if (type == OBJ_BLOB) {
> if (ls_options & LS_TREE_ONLY)
> @@ -204,6 +206,13 @@ static void show_tree_common_default_long(struct show_tree_data *data)
> {
> int base_len = data->base->len;
>
> + if (data->size_text)
> + printf("%06o %s %s %7s\t", data->mode, type_name(data->type),
> + find_unique_abbrev(data->oid, abbrev), data->size_text);
> + else
> + printf("%06o %s %s\t", data->mode, type_name(data->type),
> + find_unique_abbrev(data->oid, abbrev));
> +
> strbuf_addstr(data->base, data->pathname);
> write_name_quoted_relative(data->base->buf,
> chomp_prefix ? ls_tree_prefix : NULL, stdout,
> @@ -223,8 +232,6 @@ static int show_tree_default(const struct object_id *oid, struct strbuf *base,
> if (early >= 0)
> return early;
>
> - printf("%06o %s %s\t", data.mode, type_name(data.type),
> - find_unique_abbrev(data.oid, abbrev));
> show_tree_common_default_long(&data);
> return recurse;
> }
> @@ -253,8 +260,7 @@ static int show_tree_long(const struct object_id *oid, struct strbuf *base,
> xsnprintf(size_text, sizeof(size_text), "-");
> }
>
> - printf("%06o %s %s %7s\t", data.mode, type_name(data.type),
> - find_unique_abbrev(data.oid, abbrev), size_text);
> + data.size_text = size_text;
> show_tree_common_default_long(&data);
> return recurse;
> }
I think this is a good example of how not to split up commits.
So, in this case the reader is left wondering what the point is, how
does having two callers, and introducing an exra parameter to flip
between what one or the other wants make sense for a "common" function?
It doesn't, that code should just belong in those callers, so this is
just making things more indirect.
We find out later in the series that the real reason is that this
eventually becomes an append to a "struct strbuf".
At that point we need to re-write these lines again, so in terms of
reviewers having to look at it they'd wonder here, and then look a that
code again...
This is better just either squashed into a 6/6, or in an explicit
"here's some refactoring to make a subsequent change smaller", which
e.g. could move to using the strbuf already, which we'd later make "real" use of.
next prev parent reply other threads:[~2022-11-17 14:02 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-17 11:30 [RFC PATCH 0/6] ls-tree: introduce '--pattern' option Teng Long
2022-11-17 11:30 ` [RFC PATCH 1/6] ls-tree: cleanup the redundant SPACE Teng Long
2022-11-17 11:30 ` [RFC PATCH 2/6] t3104: remove shift code in 'test_ls_tree_format' Teng Long
2022-11-17 11:30 ` [RFC PATCH 3/6] ls-tree: optimize params of 'show_tree_common_default_long()' Teng Long
2022-11-17 11:30 ` [RFC PATCH 4/6] ls-tree: improving cohension in the print code Teng Long
2022-11-17 13:53 ` Ævar Arnfjörð Bjarmason [this message]
2022-11-17 11:30 ` [RFC PATCH 5/6] ls-tree: introduce 'match_pattern()' function Teng Long
2022-11-17 14:02 ` Ævar Arnfjörð Bjarmason
2022-11-30 9:39 ` Ævar Arnfjörð Bjarmason
2022-11-17 11:30 ` [RFC PATCH 6/6] ls-tree: introduce '--pattern' option Teng Long
2022-11-17 14:03 ` Ævar Arnfjörð Bjarmason
2022-12-12 8:32 ` Johannes Schindelin
2022-12-12 23:57 ` Junio C Hamano
2022-12-14 5:27 ` Junio C Hamano
2022-12-14 10:03 ` Ævar Arnfjörð Bjarmason
2022-12-14 10:38 ` Junio C Hamano
2023-03-27 10:37 ` win-test: unknown terminal "xterm-256color", was " Johannes Schindelin
2023-03-27 20:42 ` Junio C Hamano
2023-03-28 18:08 ` Jeff King
2023-03-28 19:31 ` Junio C Hamano
2023-03-28 19:59 ` Jeff King
2023-03-28 20:43 ` Jeff King
2023-03-28 21:05 ` Junio C Hamano
2022-11-17 13:22 ` [RFC PATCH 0/6] " Ævar Arnfjörð Bjarmason
2022-11-17 22:02 ` Taylor Blau
2022-11-21 11:41 ` Teng Long
2022-11-21 12:12 ` Ævar Arnfjörð Bjarmason
2022-11-17 13:48 ` [RFC PATCH 0/4] ls-tree: pass state in struct, not globals Ævar Arnfjörð Bjarmason
2022-11-17 13:48 ` [RFC PATCH 1/4] ls-tree: don't use "show_tree_data" for "fast" callbacks Ævar Arnfjörð Bjarmason
2022-12-21 11:47 ` Teng Long
2022-11-17 13:48 ` [RFC PATCH 2/4] ls-tree: use a "struct options" Ævar Arnfjörð Bjarmason
2022-11-17 13:48 ` [RFC PATCH 3/4] ls-tree: fold "show_tree_data" into "cb" struct Ævar Arnfjörð Bjarmason
2022-11-17 13:48 ` [RFC PATCH 4/4] ls-tree: make "line_termination" less generic Ævar Arnfjörð Bjarmason
2022-11-21 12:00 ` [RFC PATCH 0/4] ls-tree: pass state in struct, not globals Teng Long
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=221117.86fsehisrw.gmgdl@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=dyroneteng@gmail.com \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.com \
--cc=tenglong.tl@alibaba-inc.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).