From: Junio C Hamano <gitster@pobox.com>
To: Alex Riesen <raa.lkml@gmail.com>
Cc: Jay Soffian <jaysoffian@gmail.com>,
git@vger.kernel.org,
Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH] branch: optionally setup branch.*.merge from upstream local branches
Date: Tue, 19 Feb 2008 16:48:05 -0800 [thread overview]
Message-ID: <7v4pc4fo6y.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20080220001339.GA16574@steel.home> (Alex Riesen's message of "Wed, 20 Feb 2008 01:13:39 +0100")
Alex Riesen <raa.lkml@gmail.com> writes:
> Well, it could also mean that there is no rules yet, and you can
> do the next sane thing of your choice.
>
>> enum color_branch {
>> COLOR_BRANCH_RESET = 0,
>> COLOR_BRANCH_PLAIN = 1,
>> COLOR_BRANCH_REMOTE = 2,
>> COLOR_BRANCH_LOCAL = 3,
>> COLOR_BRANCH_CURRENT = 4,
>> };
This enum is used as an index into branch_colors[] array. Of
course, by omitting everything you will get the default "start
with 0, incrementing by 1" which will be the right assignment
anyway. But we would want to leave a clue for people who would
want to touch this later that individual values have some
meaning, more than just that they have to be distinct.
>> enum {
>> TAGS_UNSET = 0,
>> TAGS_DEFAULT = 1,
>> TAGS_SET = 2
>> };
This one can be made unspecified or even shuffled, because
nobody does:
int function_that_acts_on_tag_setting(int tag) {
if (!tag) {
... do something ...
}
if (TAGS_DEFAULT <= tag) {
... do something else ...
}
return some_array[tag];
}
So there is no reason to spell out any of the values.
>> enum update_mode { BOTH = 0, WORKING_DIRECTORY, INDEX } *modes;
Likewise.
>> enum exist_status {
>> index_nonexistent = 0,
>> index_directory,
>> index_gitdir,
>> };
Likewise, modulo that making "nonexistent" explicitly to 0 is a
very sensible thing whoever wrote that code has done. This is
used as a type of directory_exists_in_index() function, and
callers can say:
if (!directory_exists_in_index(dirname)) {
... ah, there is no such directory ...
} else {
... something exists, but I do not care what kind ...
}
So spelling out that "nonexistent MUST BE 0" (even though C
language will give value 0 to it anyway) is a good convention.
>> enum CAPABILITY {
>> NOLOGIN = 0,
>> UIDPLUS,
>> LITERALPLUS,
>> NAMESPACE,
>> };
This seems to be meant to match the order in the corresponding
cap_list[] array, so this cannot be reshuffled (iow, it is
similar to color_branch).
If you do not need to have any specific value assigned nor order
among the enum tokens, (i.e. somebody later can add a new enum
anywhere in the decl or even reshuffle the existing ones without
breaking your code), it is a good idea to hint that fact by not
having any "= value" in the decl. If you do rely on specific
one being zero (see "exist_status" example above), it is better
to spell it out that it has to be zero even if it is the first
entry to hint that fact. Of course, if you need a set of values
that are not sequential, you would need to spell out each and
every one of them.
next prev parent reply other threads:[~2008-02-20 0:49 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-19 2:07 [PATCH] branch: optionally setup branch.*.merge from upstream local branches Jay Soffian
2008-02-19 2:19 ` Jay Soffian
2008-02-19 10:55 ` Johannes Schindelin
2008-02-19 13:42 ` Jay Soffian
2008-02-19 13:59 ` Jay Soffian
2008-02-19 14:01 ` Johannes Schindelin
2008-02-19 5:52 ` Junio C Hamano
2008-02-19 13:40 ` Jay Soffian
2008-02-19 7:44 ` Alex Riesen
2008-02-19 13:49 ` Jay Soffian
2008-02-19 13:53 ` Johannes Schindelin
2008-02-20 0:13 ` Alex Riesen
2008-02-20 0:48 ` Junio C Hamano [this message]
2008-02-20 0:55 ` Junio C Hamano
-- strict thread matches above, loose matches on Subject: below --
2008-02-18 13:53 Jay Soffian
2008-02-18 14:05 ` Johannes Schindelin
2008-02-18 14:38 ` Jay Soffian
2008-02-18 18:47 ` Johannes Schindelin
2008-02-18 20:59 ` Junio C Hamano
2008-02-18 13:24 Jay Soffian
2008-02-18 13:29 ` Johannes Schindelin
2008-02-18 19:00 ` Mike Hommey
2008-02-18 12:04 Jay Soffian
2008-02-18 12:14 ` Johannes Schindelin
2008-02-18 12:40 ` Jay Soffian
2008-02-18 13:24 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7v4pc4fo6y.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=jaysoffian@gmail.com \
--cc=raa.lkml@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).