git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Couder <chriscool@tuxfamily.org>
To: gitster@pobox.com
Cc: christian.couder@gmail.com, karsten.blees@gmail.com,
	git@vger.kernel.org, peff@peff.net, joey@kitenet.net,
	sunshine@sunshineco.com
Subject: Re: [PATCH v3 07/10] builtin/replace: teach listing using short, medium or full formats
Date: Sat, 28 Dec 2013 11:27:01 +0100 (CET)	[thread overview]
Message-ID: <20131228.112701.1954502091799602077.chriscool@tuxfamily.org> (raw)
In-Reply-To: <xmqqppojctsh.fsf@gitster.dls.corp.google.com>

From: Junio C Hamano <gitster@pobox.com>
>
> Christian Couder <christian.couder@gmail.com> writes: 
>>
>> Ok, so would you prefer the following:
>>
>> - NAME_ONLY_REPLACE_FMT and "--format=name_only" instead of
>> SHORT_REPLACE_FMT and "--format=short"
>>
>> - NAME_AND_VALUE_REPLACE_FMT and "--format=name_and_value" instead of
>> MEDIUM_REPLACE_FMT and "--format=medium"
>>
>> - DEBUG_REPLACE_FMT and "--format=debug" instead of FULL _REPLACE_FMT
>> and "--format=full"
> 
> The end-user facing names are probably fine with short, medium,
> full, as long as what they show are clearly explained in the
> end-user documentation (patch 10/10 covers this).

Ok, I will try to improve on that.

> I have a hunch that we may later regret "full" when somebody wants
> to add even fuller information, though. It might be better spelled
> "long" instead;

Ok, I will use "long" instead.

> I'd rather see REPLACE_FMT_ as a prefix, not suffix.  Do we use
> common suffix for enum values elsewhere?

I don't see common suffix, but we have the following enums about
formats:

* in builtin/commit.c:

static enum status_format {
        STATUS_FORMAT_NONE = 0,
        STATUS_FORMAT_LONG,
        STATUS_FORMAT_SHORT,
        STATUS_FORMAT_PORCELAIN,

        STATUS_FORMAT_UNSPECIFIED
} status_format = STATUS_FORMAT_UNSPECIFIED;

* in builtin/help.c:

enum help_format {
        HELP_FORMAT_NONE,
        HELP_FORMAT_MAN,
        HELP_FORMAT_INFO,
        HELP_FORMAT_WEB
};

* in commit.h

enum cmit_fmt {
        CMIT_FMT_RAW,
        CMIT_FMT_MEDIUM,
        CMIT_FMT_DEFAULT = CMIT_FMT_MEDIUM,
        CMIT_FMT_SHORT,
        CMIT_FMT_FULL,
        CMIT_FMT_FULLER,
        CMIT_FMT_ONELINE,
        CMIT_FMT_EMAIL,
        CMIT_FMT_USERFORMAT,

        CMIT_FMT_UNSPECIFIED
};

To conform to the above and what you suggest, I will send a new series
using the following:

enum replace_format {
      REPLACE_FORMAT_SHORT,
      REPLACE_FORMAT_MEDIUM,
      REPLACE_FORMAT_LONG
};

Thanks,
Christian.

  reply	other threads:[~2013-12-28 10:27 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-11  7:46 [PATCH v3 00/10] teach replace objects to sha1_object_info_extended() Christian Couder
2013-12-11  7:46 ` [PATCH v3 01/10] Rename READ_SHA1_FILE_REPLACE flag to LOOKUP_REPLACE_OBJECT Christian Couder
2013-12-11  7:46 ` [PATCH v3 02/10] replace_object: don't check read_replace_refs twice Christian Couder
2013-12-11  7:46 ` [PATCH v3 03/10] Introduce lookup_replace_object_extended() to pass flags Christian Couder
2013-12-11  7:46 ` [PATCH v3 04/10] Add an "unsigned flags" parameter to sha1_object_info_extended() Christian Couder
2013-12-11  7:46 ` [PATCH v3 05/10] t6050: show that git cat-file --batch fails with replace objects Christian Couder
2013-12-11  7:46 ` [PATCH v3 06/10] sha1_file: perform object replacement in sha1_object_info_extended() Christian Couder
2013-12-11  7:46 ` [PATCH v3 07/10] builtin/replace: teach listing using short, medium or full formats Christian Couder
2013-12-18 12:37   ` Karsten Blees
2013-12-18 16:49     ` Christian Couder
2013-12-18 17:37       ` Junio C Hamano
2013-12-19 16:36         ` Christian Couder
2013-12-19 18:58           ` Junio C Hamano
2013-12-21  9:34             ` Christian Couder
2013-12-26 19:10               ` Junio C Hamano
2013-12-28 10:27                 ` Christian Couder [this message]
2013-12-11  7:46 ` [PATCH v3 08/10] t6050: add tests for listing with --format Christian Couder
2013-12-11  7:46 ` [PATCH v3 09/10] builtin/replace: unset read_replace_refs Christian Couder
2013-12-11  7:46 ` [PATCH v3 10/10] Documentation/git-replace: describe --format option Christian Couder
2013-12-12 20:05 ` [PATCH v3 00/10] teach replace objects to sha1_object_info_extended() 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=20131228.112701.1954502091799602077.chriscool@tuxfamily.org \
    --to=chriscool@tuxfamily.org \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=joey@kitenet.net \
    --cc=karsten.blees@gmail.com \
    --cc=peff@peff.net \
    --cc=sunshine@sunshineco.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).