Re: [PATCH v3 07/10] builtin/replace: teach listing using short, medium or full formats

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH v3 07/10] builtin/replace: teach listing using short, medium or full formats

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:59:30

Christian Couder [off-list ref] writes:
On Thu, Dec 19, 2013 at 7:58 PM, Junio C Hamano [off-list ref] wrote:
quoted
Christian Couder [off-list ref] writes:
quoted
I think this last one might be useful for people replacing objects
with objects that have another type.
... which IIUC is strongly discouraged---didn't you have to tighten
it recently?

And that makes it "useful primarily for debugging" unusual
situations.
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).

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;

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

Re: [PATCH v3 07/10] builtin/replace: teach listing using short, medium or full formats

From: Christian Couder <hidden>
Date: 2016-06-15 22:59:31

From: Junio C Hamano <redacted>
Christian Couder [off-list ref] writes: 
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help