git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff Hostetler <jeffhost@microsoft.com>
Cc: git@vger.kernel.org, git@jeffhostetler.com, peff@peff.net,
	Johannes.Schindelin@gmx.de
Subject: Re: [PATCH v2 4/8] status: per-file data collection for --porcelain=v2
Date: Mon, 25 Jul 2016 13:14:30 -0700	[thread overview]
Message-ID: <xmqq1t2h5vbt.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <1469474750-49075-5-git-send-email-jeffhost@microsoft.com> (Jeff Hostetler's message of "Mon, 25 Jul 2016 15:25:46 -0400")

Jeff Hostetler <jeffhost@microsoft.com> writes:

> +static void aux_updated_entry_porcelain_v2(
> +	struct wt_status *s,
> +	struct wt_status_change_data *d,
> +	struct diff_filepair *p)
> +{
> +	switch (p->status) {
> +	case DIFF_STATUS_ADDED:
> +		/* {mode,sha1}_head are zero for an add. */
> +		d->aux.porcelain_v2.mode_index = p->two->mode;

I doubt that it makes sense in the longer term to have a new "aux"
field.  Why isn't it part of the wt_status_change_data structure?
For that matter, why should these new functions have both "aux" and
"v2" in their names?

Imagine what should happen when somebody wants to add --porcelain=v3
format in 6 months.  Why must "v3" be treated differently from "v1"
and in a way close to "v2"?  Why shouldn't all the three be treated
in a similar way that "v1" has already?

> +		oidcpy(&d->aux.porcelain_v2.oid_index, &p->two->oid);
> +		break;
> +
> +	case DIFF_STATUS_DELETED:
> +		d->aux.porcelain_v2.mode_head = p->one->mode;
> +		oidcpy(&d->aux.porcelain_v2.oid_head, &p->one->oid);
> +		/* {mode,oid}_index are zero for a delete. */
> +		break;
> +
> +	case DIFF_STATUS_RENAMED:
> +		d->aux.porcelain_v2.rename_score = p->score * 100 / MAX_SCORE;

I have a slight aversion against losing the precision in a helper
function like this that does not do the actual output, but it
probably is OK.

Don't we have copy detection score that is computed exactly the same
way for DIFF_STATUS_COPIED case, too?

For readability, unless a case arm is completely empty, we should
have
		/* fallthru */

comment where "break;" would go for a normal case arm.

> +	case DIFF_STATUS_COPIED:
> +	case DIFF_STATUS_MODIFIED:
> +	case DIFF_STATUS_TYPE_CHANGED:
> +	case DIFF_STATUS_UNMERGED:
> +		d->aux.porcelain_v2.mode_head = p->one->mode;
> +		d->aux.porcelain_v2.mode_index = p->two->mode;
> +		oidcpy(&d->aux.porcelain_v2.oid_head, &p->one->oid);
> +		oidcpy(&d->aux.porcelain_v2.oid_index, &p->two->oid);
> +		break;

  reply	other threads:[~2016-07-25 20:14 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-25 19:25 [PATCH v2 0/8] status: V2 porcelain status Jeff Hostetler
2016-07-25 19:25 ` [PATCH v2 1/8] status: rename long-format print routines Jeff Hostetler
2016-07-25 19:25 ` [PATCH v2 2/8] status: cleanup API to wt_status_print Jeff Hostetler
2016-07-25 20:05   ` Junio C Hamano
2016-07-25 19:25 ` [PATCH v2 3/8] status: support --porcelain[=<version>] Jeff Hostetler
2016-07-25 19:51   ` Jakub Narębski
2016-07-25 19:25 ` [PATCH v2 4/8] status: per-file data collection for --porcelain=v2 Jeff Hostetler
2016-07-25 20:14   ` Junio C Hamano [this message]
2016-07-26 13:31     ` Jeff Hostetler
2016-07-25 19:25 ` [PATCH v2 5/8] status: print per-file porcelain v2 status data Jeff Hostetler
2016-07-25 20:23   ` Junio C Hamano
2016-07-26 13:53     ` Jeff Hostetler
2016-07-25 19:25 ` [PATCH v2 6/8] status: print branch info with --porcelain=v2 --branch Jeff Hostetler
2016-07-25 20:30   ` Junio C Hamano
2016-07-25 19:25 ` [PATCH v2 7/8] status: update git-status.txt for --porcelain=v2 Jeff Hostetler
2016-07-25 22:43   ` Jakub Narębski
2016-07-26 15:34     ` Johannes Schindelin
2016-07-26 19:42     ` Jeff Hostetler
2016-07-25 19:25 ` [PATCH v2 8/8] status: tests " Jeff Hostetler
2016-07-26 16:07   ` Johannes Schindelin

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=xmqq1t2h5vbt.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@jeffhostetler.com \
    --cc=git@vger.kernel.org \
    --cc=jeffhost@microsoft.com \
    --cc=peff@peff.net \
    /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).