Stefan Beller <sbel...@google.com> writes:
> For debuggers aid we'd want to print debug statements early, so
> introduce a new line in the debug output that describes the whole
> function, and the change the next debug output to describe why we need
> to search. Conveniently drop the arg from the second line; which will
> be useful in a follow up commit, that refactors the describe function.
>
> Signed-off-by: Stefan Beller <sbel...@google.com>
> ---
Adding an eary "entry" log may indeed be a good idea. This is not a
new issue, but I do not think it is a good trade-off to burden i18n
teams to translate debug-only messages, though.
> builtin/describe.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/describe.c b/builtin/describe.c
> index fd61f463cf..3136efde31 100644
> --- a/builtin/describe.c
> +++ b/builtin/describe.c
> @@ -293,6 +293,9 @@ static void describe(const char *arg, int last_one)
> unsigned long seen_commits = 0;
> unsigned int unannotated_cnt = 0;
>
> + if (debug)
> + fprintf(stderr, _("describe %s\n"), arg);
> +
> if (get_oid(arg, &oid))
> die(_("Not a valid object name %s"), arg);
> cmit = lookup_commit_reference(&oid);
> @@ -316,7 +319,7 @@ static void describe(const char *arg, int last_one)
> if (!max_candidates)
> die(_("no tag exactly matches '%s'"),
> oid_to_hex(&cmit->object.oid));
> if (debug)
> - fprintf(stderr, _("searching to describe %s\n"), arg);
> + fprintf(stderr, _("No exact match on refs or tags, searching to
> describe\n"));
>
> if (!have_util) {
> struct hashmap_iter iter;
