git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: "Stephen P. Smith" <ischis2@cox.net>,
	"Git List" <git@vger.kernel.org>,
	"Eric Sunshine" <sunshine@sunshineco.com>,
	"SZEDER Gábor" <szeder.dev@gmail.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [PATCH 1/1] roll wt_status_state into wt_status and populate in the collect phase
Date: Fri, 28 Sep 2018 11:34:41 -0700	[thread overview]
Message-ID: <xmqq4le9cvy6.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20180928135549.GA23652@syl> (Taylor Blau's message of "Fri, 28 Sep 2018 06:55:49 -0700")

Taylor Blau <me@ttaylorr.com> writes:

> 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.

>> 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.

>>  	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.

  reply	other threads:[~2018-09-28 18:34 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-06  0:53 [PATCH v3 0/4] wt-status.c: commitable flag Stephen P. Smith
2018-09-06  0:53 ` [PATCH v3 1/4] Move has_unmerged earlier in the file Stephen P. Smith
2018-09-06  0:53 ` [PATCH v3 2/4] wt-status: rename commitable to committable Stephen P. Smith
2018-09-07 21:38   ` Junio C Hamano
2018-09-06  0:53 ` [PATCH v3 3/4] t7501: add test of "commit --dry-run --short" Stephen P. Smith
2018-09-06  0:53 ` [PATCH v3 4/4] wt-status.c: Set the committable flag in the collect phase Stephen P. Smith
2018-09-07 22:01   ` Junio C Hamano
2018-09-07 22:31     ` Junio C Hamano
2018-09-28  4:49       ` [PATCH 0/1] wt-status-state-cleanup Stephen P. Smith
2018-09-28  4:49         ` [PATCH 1/1] roll wt_status_state into wt_status and populate in the collect phase Stephen P. Smith
2018-09-28 13:55           ` Taylor Blau
2018-09-28 18:34             ` Junio C Hamano [this message]
2018-09-29 18:55               ` [PATCH v2 0/1] wt-status-state-cleanup Stephen P. Smith
2018-09-29 18:55                 ` [PATCH v2 1/1] roll wt_status_state into wt_status and populate in the collect phase Stephen P. Smith
2018-09-30  4:41                   ` Eric Sunshine
2018-09-30 14:12                     ` [PATCH v3 0/1] wt-status-state-cleanup Stephen P. Smith
2018-09-30 14:12                       ` [PATCH v3 1/1] roll wt_status_state into wt_status and populate in the collect phase Stephen P. Smith
2018-09-30  4:40             ` [PATCH " Eric Sunshine
2018-09-07 23:55     ` [PATCH v3 4/4] wt-status.c: Set the committable flag " Stephen P. Smith
2018-09-11 17:22       ` Junio C Hamano
2018-09-24  3:15     ` Stephen Smith
2018-09-24 21:02       ` Junio C Hamano
2018-09-06  7:38 ` [PATCH v3 0/4] wt-status.c: commitable flag Ævar Arnfjörð Bjarmason
2018-09-06 16:06 ` Stephen & Linda Smith
2018-09-07 21:40 ` 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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq4le9cvy6.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=ischis2@cox.net \
    --cc=me@ttaylorr.com \
    --cc=sunshine@sunshineco.com \
    --cc=szeder.dev@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).