Re: [PATCHv3 5/7] builtin/describe.c: print debug statements earlier
- From
Stefan Beller <sbeller@google.com>
- Date
- Nov 14, 2017, 20:00 UTC
- Message-ID
- <CAGZ79kaj86+hxfXqROAcSUdSTOY-8CuWFv=XRP3isD3PAx2fHA@mail.gmail.com>
- In-Reply-To
- <20171114115512.a3ba15c0325b1eefa2602984@google.com>
On Tue, Nov 14, 2017 at 11:55 AM, Jonathan Tan <jonathantanmy@google.com> wrote:
Show 45 quoted lines
> On Thu, 2 Nov 2017 12:41:46 -0700
> Stefan Beller <sbeller@google.com> wrote:
>
>> 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 then 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 <sbeller@google.com>
>> ---
>> 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);
>> +
>
> Could you explain in the commit message why this wasn't needed before
> (if it wasn't needed), and why this is needed now?
>
>> 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"));
>
> What is this arg that can be safely dropped?
>
> You mention that it is for convenience (since the describe() function
> will be refactored), but could the arg just be passed to the new
> function?It could, but I want to avoid that just to print a debugging statement inside the function. So I factor the debugging printing out of the function introduced in the next patch.