git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Matthieu Moy <Matthieu.Moy@imag.fr>
Cc: git@vger.kernel.org, gitster@pobox.com, javierdo1@gmail.com,
	jrnieder@gmail.com, judge.packham@gmail.com
Subject: Re: [PATCH 1/2] wt-status: turn advice_status_hints into a field of wt_status
Date: Wed, 11 Sep 2013 14:35:20 -0400	[thread overview]
Message-ID: <20130911183519.GA24251@sigill.intra.peff.net> (raw)
In-Reply-To: <1378890539-1966-1-git-send-email-Matthieu.Moy@imag.fr>

On Wed, Sep 11, 2013 at 11:08:58AM +0200, Matthieu Moy wrote:

> No behavior change in this patch, but this makes the display of status
> hints more flexible as they can be enabled or disabled for individual
> calls to commit.c:run_status().
> [...]
> +static void status_finalize(struct wt_status *s)
> +{
> +	determine_whence(s);
> +	s->hints = advice_status_hints;
> +}

Is a "finalize" the right place to put the status hint tweak? I would
expect the order for callers to be:

  wt_status_prepare(&s);
  /* manual tweaks of fields in "s" */
  wt_status_finalize(&s);

but the finalize would overwrite any tweak of the hints field. So it
would make more sense to me for it to go in prepare().

But the current callsites look like this:

> @@ -1249,7 +1255,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)
>  	wt_status_prepare(&s);
>  	gitmodules_config();
>  	git_config(git_status_config, &s);
> -	determine_whence(&s);
> +	status_finalize(&s);
>  	argc = parse_options(argc, argv, prefix,
>  			     builtin_status_options,
>  			     builtin_status_usage, 0);

We do not actually read the config until after _prepare, because the
config is what is doing the tweaking of "s" in this case. But we cannot
trust advice_* until we have read the config.

The problem is that we are doing two things in that git_config call:

  1. Loading basic git-wide core config.

  2. Priming the wt_status struct with options specific to "git status"

So the "cleanest" thing would be something like:

  /* load basic config */
  git_config(git_diff_ui_config, NULL);

  /* initialize the status-run struct; this would probably be better named as
   * _init to match the rest of the code */
  wt_status_prepare(&s);

  /* now tweak the defaults using status-specific config, which does
   * not need to chain to other config callbacks anymore */
  git_config(git_status_config, &s);

  /* and then tweak further with command line options */
  argc = parse_options(...);

  /* and now finally ask wt-status to finalize any setup we've put into
     the struct (e.g., calling determine_whence, though I do not
     actually see it depending on any of the fields we set. Should it
     be part of _prepare? */
  wt_status_finalize(&s);


That would follow our more usual object init-tweak-finalize-use
patterns. Hrm. To make matters more complicated, we have
finalize_deferred_config, too. I think that could be rolled into
wt_status_finalize.

Perhaps that is getting a bit complicated as a refactor. If you don't
want to do it, I understand, but I think you should probably avoid the
name "_finalize" here, as it is a bit mis-leading.

-Peff

  parent reply	other threads:[~2013-09-11 18:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-11  9:08 [PATCH 1/2] wt-status: turn advice_status_hints into a field of wt_status Matthieu Moy
2013-09-11  9:08 ` [PATCH 2/2] commit: disable status hints when writing to COMMIT_EDITMSG Matthieu Moy
2013-09-11  9:13   ` Eric Sunshine
2013-09-11 18:35 ` Jeff King [this message]
2013-09-12  9:44   ` [PATCH 1/2] wt-status: turn advice_status_hints into a field of wt_status Matthieu Moy
2013-09-12  9:52     ` Jeff King

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=20130911183519.GA24251@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=Matthieu.Moy@imag.fr \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=javierdo1@gmail.com \
    --cc=jrnieder@gmail.com \
    --cc=judge.packham@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).