git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Subject: [PATCH 0/2] Simplify "commented" API functions
Date: Thu, 12 Sep 2024 13:52:59 -0700	[thread overview]
Message-ID: <20240912205301.1809355-1-gitster@pobox.com> (raw)

We [earlier] noticed that a few helper functions that format strings
into a strbuf, prefixed with an arbitrary comment leading character,
are forcing their callers to always pass the same argument.  Instead
of keeping this excess flexibility nobody wants in practice, narrow
the API so that all callers of these functions will get the same
comment leading character.

Superficially it may appear that this goes against one of the recent
trend, "war on global variables", but I doubt it matters much in the
longer run.

These call sites all have already been relying on the global
"comment_line_str" anyway, and passing the variable from the top of
arbitrary deep call chain, which may not care specifically about
this single variable comment_line_str, would not scale as a
solution.  If we were to make it a convention to pass something from
the very top of the call chain everywhere, it should not be an
individual variable that is overly specific, like comment_line_str.
Rather, it has to be something that allows access to a bag of all
the global settings (possibly wider than "the_repository" struct).
We can also limit our reliance to the globals by allowing a single
global function call to obtaion such a bag of all global settings,
i.e. "get_the_environment()", and allow everybody, including
functions at the leaf level, to ask "what is the comment_line_str in
the environment I am working in?".  As part of the libification, we
can plug in an appropriate shim for get_the_environment().


[earlier] https://lore.kernel.org/git/xmqq7cn4g3nx.fsf@gitster.g/

Junio C Hamano (2):
  strbuf: retire strbuf_commented_addf()
  strbuf: retire strbuf_commented_lines()

 add-patch.c          |  8 ++++----
 builtin/branch.c     |  2 +-
 builtin/merge.c      |  8 ++++----
 builtin/notes.c      | 10 +++++-----
 builtin/stripspace.c |  2 +-
 builtin/tag.c        |  4 ++--
 fmt-merge-msg.c      | 17 +++++++----------
 rebase-interactive.c |  8 ++++----
 sequencer.c          | 16 +++++++---------
 strbuf.c             | 11 +++++------
 strbuf.h             | 13 +++++--------
 wt-status.c          |  6 +++---
 12 files changed, 48 insertions(+), 57 deletions(-)

-- 
2.46.0-717-g3841ff3f09


             reply	other threads:[~2024-09-12 20:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-12 20:52 Junio C Hamano [this message]
2024-09-12 20:53 ` [PATCH 1/2] strbuf: retire strbuf_commented_addf() Junio C Hamano
2024-09-12 20:53 ` [PATCH 2/2] strbuf: retire strbuf_commented_lines() Junio C Hamano
2024-10-29 20:53   ` Kristoffer Haugsbakk
2024-09-12 21:57 ` [PATCH 0/2] Simplify "commented" API functions Junio C Hamano
2024-09-13  6:15 ` Patrick Steinhardt
2024-09-13 17:23   ` Junio C Hamano

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=20240912205301.1809355-1-gitster@pobox.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    /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).