Re: [PATCH 1/1] roll wt_status_state into wt_status and populate in the collect phase

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 28, 2018, 18:34 UTC
Message-ID: <xmqq4le9cvy6.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20180928135549.GA23652@syl>

Taylor Blau <me@ttaylorr.com> writes:

Show 7 quoted lines

> On Thu, Sep 27, 2018 at 09:49:36PM -0700, Stephen P. Smith wrote:
>> When updating the collect and print functions, it was found that
>> status variables were initialized in the collect phase and some
>> variables were later freed in the print functions.
>
> Nit: I think that in the past Eric Sunshine has recommended that I use
> active voice in patches, but "it was found" is passive.

Yeah, and when/how it was found is much less interesting backstory than _why_ we are doing this follow-thru. I think the first line can just simply go without losing clarity.

>> Move the status state structure variables into the status state
>> structure and populate them in the collect functions.

On the other hand this one may deserve a bit more backstory. If I understand correctly, what happened over time was

 - A "struct wt_status" used to be sufficient for the output phase
   to work.  It was designed to be filled in the collect phase and
   consumed in the output phase, but over time some fields are added
   and output phase started filling it; we recently corrected it so
   that .committable field is filled in the collect phase.

   A "struct wt_status_state" that was used in other codepaths
   turned out to be useful in showing the "git status" output, so
   some output phase functions started taking it.  This is not tied
   to "struct wt_status", so the discipline of filling in the
   collect phase to be consumed in the output phase was never
   followed.

I am not suggesting to write that much in the log message, but and with a backstory like that, embedding a wt_status_state inside wt_status and fill it in the collect phase, which this patch does, starts to make sense, I would think.

Show 14 quoted lines

>> diff --git a/wt-status.c b/wt-status.c
>> index c7f76d4758..9977f0cdf2 100644
>> --- a/wt-status.c
>> +++ b/wt-status.c
>> @@ -744,21 +744,26 @@ static int has_unmerged(struct wt_status *s)
>>
>>  void wt_status_collect(struct wt_status *s)
>>  {
>> -	struct wt_status_state state;
>>  	wt_status_collect_changes_worktree(s);
>> -
>
> Nit: unnecessary diff, but I certainly don't think that this is worth a
> re-roll on its own.

I do not think it is unnecessary to remove the blank between three things this function does (i.e. (1) inspect working tree, (2) inspect index and (3) inspect untrackeed; if there is no blank line between (2) and (3), we shouldn't have a blank between (1) and (2)).

I do agree with you it is an unrelated change. Its correctness (not to the compiler, but to the humans due to the above) is so trivial that it probably is a good taste to include it in this patch.

Show 14 quoted lines

>>  	if (s->is_initial)
>>  		wt_status_collect_changes_initial(s);
>>  	else
>>  		wt_status_collect_changes_index(s);
>>  	wt_status_collect_untracked(s);
>>
>> -	memset(&state, 0, sizeof(state));
>> -	wt_status_get_state(&state, s->branch && !strcmp(s->branch, "HEAD"));
>> -	if (state.merge_in_progress && !has_unmerged(s))
>> +	wt_status_get_state(&s->state, s->branch && !strcmp(s->branch, "HEAD"));
>> +	if (s->state.merge_in_progress && !has_unmerged(s))
>>  		s->committable = 1;
>
> Should this line be de-dented to match the above?

I am not sure if I follow.

Thanks.