Johannes Schindelin <johannes.schinde...@gmx.de> writes:
> This makes the code DRYer, with the obvious benefit that we can enhance
> the code further in a single place.
>
> We can also reuse the functionality elsewhere by calling this new
> function.
>
> Signed-off-by: Johannes Schindelin <johannes.schinde...@gmx.de>
> ---
> sequencer.c | 33 ++++++++++++++++++++++++++-------
> 1 file changed, 26 insertions(+), 7 deletions(-)
>
> diff --git a/sequencer.c b/sequencer.c
> index 33fb36dcbe..d20efad562 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -1750,6 +1750,26 @@ static int is_final_fixup(struct todo_list *todo_list)
> return 1;
> }
>
> +static const char *reflog_message(struct replay_opts *opts,
> + const char *sub_action, const char *fmt, ...)
> +{
> + va_list ap;
> + static struct strbuf buf = STRBUF_INIT;
> +
> + va_start(ap, fmt);
> + strbuf_reset(&buf);
> + strbuf_addstr(&buf, action_name(opts));
> + if (sub_action)
> + strbuf_addf(&buf, " (%s)", sub_action);
> + if (fmt) {
> + strbuf_addstr(&buf, ": ");
> + strbuf_vaddf(&buf, fmt, ap);
> + }
> + va_end(ap);
> +
> + return buf.buf;
> +}
It is unlikely for a single caller to want to format another reflog
entry after formating one but before consuming it [*1*], so this
"call this, and you can use the return value until you call it the
next time without worrying about leakage" is quite a reasonable
pattern to employ.
[Footnote]
*1* And it is unlikely that this will run in a multi-threaded
environment, either ;-)
