From: Junio C Hamano <gitster@pobox•com>
To: Toon Claes <toon@iotcl•com>
Cc: "brian m. carlson" <sandals@crustytoothpaste•net>,
"Collin Funk" <collin.funk1@gmail•com>,
git@vger•kernel.org, "Karthik Nayak" <karthik.188@gmail•com>,
"Patrick Steinhardt" <ps@pks•im>, "René Scharfe" <l.s.r@web•de>
Subject: Re: .clang-format: how useful, how often used, and how well maintained?
Date: Tue, 01 Jul 2025 14:12:21 -0700 [thread overview]
Message-ID: <xmqq1pqzk43u.fsf@gitster.g> (raw)
In-Reply-To: <xmqqh5zvk5h0.fsf@gitster.g> (Junio C. Hamano's message of "Tue, 01 Jul 2025 13:42:51 -0700")
Junio C Hamano <gitster@pobox•com> writes:
> In this particular patch, there was only one such instance that the
> tools output was noticeably more irritating than the original. With
> more excercise like this with enough positive experience (I do count
> this one as positive, if we fix the space after "foreach"), I might
> change my mind.
And for completeness, if you choose to take the tool-generated style
changes, here is what I want you to also place on top.
And then, I want those who advocate blind application of tool's
output, only because then we would have somebody else to blame for
poorly formatted code, to think if they can improve the rule to
consider these points as well.
Thanks.
--- >8 ---
Subject: [PATCH] (style) fix bad changes suggested by clang-format
* The commands array in git.c is traditionally one line per
command, a possibly long line is not wrapped for grep-ability.
* No SP between "foreach" and "(".
* When wrapping a line, keep related things together.
---
git.c | 12 ++++--------
last-modified.c | 8 ++++----
2 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/git.c b/git.c
index 918d83762a..8ad1ce8dea 100644
--- a/git.c
+++ b/git.c
@@ -576,14 +576,10 @@ static struct cmd_struct commands[] = {
{ "merge-file", cmd_merge_file, RUN_SETUP_GENTLY },
{ "merge-index", cmd_merge_index, RUN_SETUP | NO_PARSEOPT },
{ "merge-ours", cmd_merge_ours, RUN_SETUP | NO_PARSEOPT },
- { "merge-recursive", cmd_merge_recursive,
- RUN_SETUP | NEED_WORK_TREE | NO_PARSEOPT },
- { "merge-recursive-ours", cmd_merge_recursive,
- RUN_SETUP | NEED_WORK_TREE | NO_PARSEOPT },
- { "merge-recursive-theirs", cmd_merge_recursive,
- RUN_SETUP | NEED_WORK_TREE | NO_PARSEOPT },
- { "merge-subtree", cmd_merge_recursive,
- RUN_SETUP | NEED_WORK_TREE | NO_PARSEOPT },
+ { "merge-recursive", cmd_merge_recursive, RUN_SETUP | NEED_WORK_TREE | NO_PARSEOPT },
+ { "merge-recursive-ours", cmd_merge_recursive, RUN_SETUP | NEED_WORK_TREE | NO_PARSEOPT },
+ { "merge-recursive-theirs", cmd_merge_recursive, RUN_SETUP | NEED_WORK_TREE | NO_PARSEOPT },
+ { "merge-subtree", cmd_merge_recursive, RUN_SETUP | NEED_WORK_TREE | NO_PARSEOPT },
{ "merge-tree", cmd_merge_tree, RUN_SETUP },
{ "mktag", cmd_mktag, RUN_SETUP },
{ "mktree", cmd_mktree, RUN_SETUP },
diff --git a/last-modified.c b/last-modified.c
index f7f6a67d3b..dfa3b2d324 100644
--- a/last-modified.c
+++ b/last-modified.c
@@ -116,7 +116,7 @@ void last_modified_release(struct last_modified *lm)
struct hashmap_iter iter;
struct last_modified_entry *ent;
- hashmap_for_each_entry (&lm->paths, &iter, ent, hashent)
+ hashmap_for_each_entry(&lm->paths, &iter, ent, hashent)
clear_bloom_key(&ent->key);
hashmap_clear_and_free(&lm->paths, struct last_modified_entry, hashent);
@@ -210,7 +210,7 @@ static int maybe_changed_path(struct last_modified *lm, struct commit *origin)
if (!filter)
return 1;
- hashmap_for_each_entry (&lm->paths, &iter, ent, hashent) {
+ hashmap_for_each_entry(&lm->paths, &iter, ent, hashent) {
if (bloom_filter_contains(filter, &ent->key,
lm->rev.bloom_filter_settings))
return 1;
@@ -218,8 +218,8 @@ static int maybe_changed_path(struct last_modified *lm, struct commit *origin)
return 0;
}
-int last_modified_run(struct last_modified *lm, last_modified_callback cb,
- void *cbdata)
+int last_modified_run(struct last_modified *lm,
+ last_modified_callback cb, void *cbdata)
{
struct last_modified_callback_data data;
--
2.50.0-278-g6118fc98aa
next prev parent reply other threads:[~2025-07-01 21:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-19 16:38 .clang-format: how useful, how often used, and how well maintained? Junio C Hamano
2025-06-19 20:30 ` Christian Couder
2025-06-20 0:20 ` Junio C Hamano
2025-06-20 14:08 ` Christian Couder
2025-06-20 16:36 ` Junio C Hamano
2025-06-21 5:07 ` Jeff King
2025-06-22 4:11 ` Junio C Hamano
2025-06-19 21:17 ` brian m. carlson
2025-06-19 21:31 ` Collin Funk
2025-06-19 22:56 ` brian m. carlson
2025-06-20 15:19 ` Junio C Hamano
2025-07-01 14:08 ` Toon Claes
2025-07-01 16:59 ` Johannes Schindelin
2025-07-01 20:42 ` Junio C Hamano
2025-07-01 21:12 ` Junio C Hamano [this message]
2025-06-23 8:46 ` Karthik Nayak
2025-06-23 16:26 ` Junio C Hamano
2025-06-24 23:27 ` Karthik Nayak
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=xmqq1pqzk43u.fsf@gitster.g \
--to=gitster@pobox$(echo .)com \
--cc=collin.funk1@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=karthik.188@gmail$(echo .)com \
--cc=l.s.r@web$(echo .)de \
--cc=ps@pks$(echo .)im \
--cc=sandals@crustytoothpaste$(echo .)net \
--cc=toon@iotcl$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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