git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Stephen P. Smith" <ischis2@cox.net>
Cc: "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 v3 4/4] wt-status.c: Set the committable flag in the collect phase.
Date: Fri, 07 Sep 2018 15:01:28 -0700	[thread overview]
Message-ID: <xmqqworxufuv.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20180906005329.11277-5-ischis2@cox.net> (Stephen P. Smith's message of "Wed, 5 Sep 2018 17:53:29 -0700")

"Stephen P. Smith" <ischis2@cox.net> writes:

>  void wt_status_collect(struct wt_status *s)
>  {
> +	struct wt_status_state state;
>  	wt_status_collect_changes_worktree(s);
>  
>  	if (s->is_initial)
> @@ -746,6 +752,11 @@ void wt_status_collect(struct wt_status *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))
> +		s->committable = 1;
>  }

I do not think this is wrong per-se, but now we have three calls to
wt_status_get_state() in wt-status.c, and it smells (at least to me)
that each of these callsites does so only because their callers
do not give them enough information, forcing them to find the state
out for themselves.

Given that the ideal paradigm to come up with the "work tree status"
is to do the collection followed by printing, and among three
callers of get_state(), two appear in the "printing" side of the
callchain [*1*], I wonder if it makes a better organization to

 - embed struct wt_status_state in struct wt_status

 - make the new call to wt_status_get_state() added above in this
   patch to populate the wt_status_state embedded in 's'

 - change the other two callers of wt_status_get_state() in
   wt_longstatus_print() and wt_porcelain_v2_print_tracking(), both
   of which will receive 's' that has been populated by a previous
   call to wt_status_collect(), so that they do *not* call
   get_state() themselves, but instead use the result recorded in
   wt_status_state embedded in 's', which was populated by
   wt_status_collect() before they got called.

That would bring the resulting code even closer to the ideal,
i.e. the "collect" phase learns _everything_ we need about the
current state that is necessary in order to later show to the user,
and the "print" phase does not do its own separate discovery.

What do you think?

Thanks.


[Reference]

*1* Here are the selected functions and what other functions they
    call.

    wt_status_collect()

     -> wt_status_collect_changes_initial()
     -> wt_status_collect_changes_index()
     -> wt_status_collect_untracked()
     -> wt_status_get_state()

    wt_longstatus_print()

     -> wt_status_get_state()

    wt_porcelain_v2_print_tracking()

     -> wt_status_get_state()


    wt_status_print()

     -> wt_porcelain_v2_print()
        -> wt_porcelain_v2_print_tracking()
     -> wt_longstatus_print()


    run_status()

     -> wt_status_collect()
     -> wt_status_print()

    cmd_status()

     -> wt_status_collect()
     -> wt_status_print()


    prepare_to_commit(), dry_run_commit()

     -> run_status()


    Most notably, wt_status_collect() always happens before
    wt_status_print(), which is natural because the former is to
    collect information in 's' that is used by the latter to print.

    And in various functions wt_status_print() calls indirectly, the
    two other callers of wt_status_get_state() appear.

  reply	other threads:[~2018-09-07 22:01 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 [this message]
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
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

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

  git send-email \
    --in-reply-to=xmqqworxufuv.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=ischis2@cox.net \
    --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.
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 NNTP newsgroup(s).