threads / patch / 21197
Subject: [PATCH 2/3] git config: clarify bool types
Felipe Contreras[PATCH 0/3] Trivial patches
These are a bunch of no-brainers. The one for bool types has been discussed and agreed before.
Felipe Contreras (3): Fix a bunch of pointer declarations (codestyle) git config: clarify bool types user-manual: use 'fast-forward'
Documentation/user-manual.txt | 14 +++++++------- builtin-config.c | 4 ++-- diff.c | 2 +- 3 files changed, 10 insertions(+), 10 deletions(-)
Felipe Contreras[PATCH 1/3] Fix a bunch of pointer declarations (codestyle)
Essentially; s/type* /type */ as per the coding guidelines.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> --- diff.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c index e1be189..b39c1b6 100644 --- a/diff.c +++ b/diff.c @@ -999,7 +999,7 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options) total_files, adds, dels); } -static void show_shortstats(struct diffstat_t* data, struct diff_options *options) +static void show_shortstats(struct diffstat_t *data, struct diff_options *options) { int i, adds = 0, dels = 0, total_files = data->nr;
-- 1.6.5.4.g31fc3
Felipe ContrerasThe value is what it is, the --bool and --bool-or-int options don't specify the value type, just how it is interpreted. For example: a value of '1' can be interpreted as 'true'.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> --- builtin-config.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-config.c b/builtin-config.c index a2d656e..29d7b75 100644 --- a/builtin-config.c +++ b/builtin-config.c @@ -66,9 +66,9 @@ static struct option builtin_config_options[] = { OPT_STRING(0, "get-color", &get_color_slot, "slot", "find the color configured: [default]"), OPT_STRING(0, "get-colorbool", &get_colorbool_slot, "slot", "find the color setting: [stdout-is-tty]"), OPT_GROUP("Type"), - OPT_BIT(0, "bool", &types, "value is \"true\" or \"false\"", TYPE_BOOL), + OPT_BIT(0, "bool", &types, "value is intepreted as bool (\"true\" or \"false\")", TYPE_BOOL), OPT_BIT(0, "int", &types, "value is decimal number", TYPE_INT), - OPT_BIT(0, "bool-or-int", &types, "value is --bool or --int", TYPE_BOOL_OR_INT), + OPT_BIT(0, "bool-or-int", &types, "value is interpreted either as bool or int", TYPE_BOOL_OR_INT), OPT_GROUP("Other"), OPT_BOOLEAN('z', "null", &end_null, "terminate values with NUL byte"), OPT_END(),
-- 1.6.5.4.g31fc3
Felipe Contreras[PATCH 3/3] user-manual: use 'fast-forward'
It's a compound word.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> --- Documentation/user-manual.txt | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 67ebffa..42d92fd 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -1384,7 +1384,7 @@ were merged. However, if the current branch is a descendant of the other--so every commit present in the one is already contained in the other--then git -just performs a "fast forward"; the head of the current branch is moved +just performs a "fast-forward"; the head of the current branch is moved forward to point at the head of the merged-in branch, without any new commits being created. @@ -1719,7 +1719,7 @@ producing a default commit message documenting the branch and repository that you pulled from. (But note that no such commit will be created in the case of a -<<fast-forwards,fast forward>>; instead, your branch will just be +<<fast-forwards,fast-forward>>; instead, your branch will just be updated to point to the latest commit from the upstream branch.) The `git pull` command can also be given "." as the "remote" repository, @@ -1943,7 +1943,7 @@ $ git push ssh://yourserver.com/~you/proj.git master ------------------------------------------------- As with `git fetch`, `git push` will complain if this does not result in a -<<fast-forwards,fast forward>>; see the following section for details on +<<fast-forwards,fast-forward>>; see the following section for details on handling this case. Note that the target of a "push" is normally a @@ -1976,7 +1976,7 @@ details. What to do when a push fails ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -If a push would not result in a <<fast-forwards,fast forward>> of the +If a push would not result in a <<fast-forwards,fast-forward>> of the remote branch, then it will fail with an error like: ------------------------------------------------- @@ -2115,7 +2115,7 @@ $ git checkout release && git pull Important note! If you have any local changes in these branches, then this merge will create a commit object in the history (with no local -changes git will simply do a "Fast forward" merge). Many people dislike +changes git will simply do a fast-forward merge). Many people dislike the "noise" that this creates in the Linux history, so you should avoid doing this capriciously in the "release" branch, as these noisy commits will become part of the permanent history when you ask Linus to pull @@ -2729,9 +2729,9 @@ In the previous example, when updating an existing branch, "git fetch" checks to make sure that the most recent commit on the remote branch is a descendant of the most recent commit on your copy of the branch before updating your copy of the branch to point at the new -commit. Git calls this process a <<fast-forwards,fast forward>>. +commit. Git calls this process a <<fast-forwards,fast-forward>>. -A fast forward looks something like this: +A fast-forward looks something like this: ................................................ o--o--o--o <-- old head of the branch
-- 1.6.5.4.g31fc3
Junio C HamanoRe: [PATCH 3/3] user-manual: use 'fast-forward'
Felipe Contreras <felipe.contreras@gmail.com> writes:
> It's a compound word.
Thanks.
This removes 7 out of 37 "fast forward" in Documentation/ directory. Are we going to convert the remaining ones, too?
Felipe ContrerasRe: [PATCH 3/3] user-manual: use 'fast-forward'
On Mon, Oct 12, 2009 at 8:05 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes: > >> It's a compound word. > > Thanks. > > This removes 7 out of 37 "fast forward" in Documentation/ directory. Are > we going to convert the remaining ones, too?
Sure. Once I finish pushing the patches I have for user-manual, which is the one I'm interested right now.
-- Felipe Contreras
Michael J GruberRe: [PATCH 3/3] user-manual: use 'fast-forward'
Felipe Contreras venit, vidit, dixit 12.10.2009 12:05:
> On Mon, Oct 12, 2009 at 8:05 AM, Junio C Hamano <gitster@pobox.com> wrote: >> Felipe Contreras <felipe.contreras@gmail.com> writes: >> >>> It's a compound word. >> >> Thanks. >> >> This removes 7 out of 37 "fast forward" in Documentation/ directory. Are >> we going to convert the remaining ones, too? > > Sure. Once I finish pushing the patches I have for user-manual, which > is the one I'm interested right now. >
And how about the other 40 or so in the remaining code?
In fact, hyphenated and separated forms of this compound noun are almost evenly split, which reflects well upon the fact that there is no clear-cut rule in US English (and neither in BE).
So, if you are suggesting a style we should define it and follow it consistently. Our main source of definitions is the glossary. Now, that has a truly salomonic solution:
fast forward A fast-forward is a special type...
I suggest that this is the first place which needs attention, after fixating the definition, maybe not just among the three of us, all non-native speakers.
Michael
Junio C HamanoRe: [PATCH 2/3] git config: clarify bool types
Felipe Contreras <felipe.contreras@gmail.com> writes:
> The value is what it is, the --bool and --bool-or-int options don't > specify the value type, just how it is interpreted. For example: a value > of '1' can be interpreted as 'true'.
It is not really about "interpreting", but about showing, isn't it?
With this in your .git/config file:
[core]
repositoryformatversion = 0you would see
$ git config --bool-or-int core.repositoryformatversion
0
$ git config --bool core.repositoryformatversion
false
$ git config --int core.repositoryformatversion
0So it would be more like...
show value as boolean
show value as integer or boolean
show value as integerwouldn't it?
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> builtin-config.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/builtin-config.c b/builtin-config.c
> index a2d656e..29d7b75 100644
> --- a/builtin-config.c
> +++ b/builtin-config.c
> @@ -66,9 +66,9 @@ static struct option builtin_config_options[] = {
> OPT_STRING(0, "get-color", &get_color_slot, "slot", "find the color configured: [default]"),
> OPT_STRING(0, "get-colorbool", &get_colorbool_slot, "slot", "find the color setting: [stdout-is-tty]"),
> OPT_GROUP("Type"),
> - OPT_BIT(0, "bool", &types, "value is \"true\" or \"false\"", TYPE_BOOL),
> + OPT_BIT(0, "bool", &types, "value is intepreted as bool (\"true\" or \"false\")", TYPE_BOOL),
> OPT_BIT(0, "int", &types, "value is decimal number", TYPE_INT),
> - OPT_BIT(0, "bool-or-int", &types, "value is --bool or --int", TYPE_BOOL_OR_INT),
> + OPT_BIT(0, "bool-or-int", &types, "value is interpreted either as bool or int", TYPE_BOOL_OR_INT),
> OPT_GROUP("Other"),
> OPT_BOOLEAN('z', "null", &end_null, "terminate values with NUL byte"),
> OPT_END(),
> --
> 1.6.5.4.g31fc3Felipe ContrerasRe: [PATCH 2/3] git config: clarify bool types
On Mon, Oct 12, 2009 at 8:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes: > >> The value is what it is, the --bool and --bool-or-int options don't >> specify the value type, just how it is interpreted. For example: a value >> of '1' can be interpreted as 'true'. > > It is not really about "interpreting", but about showing, isn't it?
Unless you are setting it, instead of reading it.
-- Felipe Contreras
Michael J GruberRe: [PATCH 2/3] git config: clarify bool types
Felipe Contreras venit, vidit, dixit 12.10.2009 12:03:
> On Mon, Oct 12, 2009 at 8:01 AM, Junio C Hamano <gitster@pobox.com> wrote: >> Felipe Contreras <felipe.contreras@gmail.com> writes: >> >>> The value is what it is, the --bool and --bool-or-int options don't >>> specify the value type, just how it is interpreted. For example: a value >>> of '1' can be interpreted as 'true'. >> >> It is not really about "interpreting", but about showing, isn't it? > > Unless you are setting it, instead of reading it. >
I'd still suggest fixing the typo ("interpreted") and spelling out "boolean".
Michael
Felipe ContrerasRe: [PATCH 2/3] git config: clarify bool types
On Mon, Oct 12, 2009 at 3:30 PM, Michael J Gruber <git@drmicha.warpmail.net> wrote:
> Felipe Contreras venit, vidit, dixit 12.10.2009 12:03:
>> On Mon, Oct 12, 2009 at 8:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> The value is what it is, the --bool and --bool-or-int options don't
>>>> specify the value type, just how it is interpreted. For example: a value
>>>> of '1' can be interpreted as 'true'.
>>>
>>> It is not really about "interpreting", but about showing, isn't it?
>>
>> Unless you are setting it, instead of reading it.
>>
>
> I'd still suggest fixing the typo ("interpreted") and spelling out
> "boolean".Oops! You mean s/intepreted/interpreted/?
If we spell 'boolean' we might as well spell 'integer'; I think bool and int are fine.
-- Felipe Contreras
Michael J GruberRe: [PATCH 2/3] git config: clarify bool types
Felipe Contreras venit, vidit, dixit 12.10.2009 19:14:
> On Mon, Oct 12, 2009 at 3:30 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Felipe Contreras venit, vidit, dixit 12.10.2009 12:03:
>>> On Mon, Oct 12, 2009 at 8:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>>
>>>>> The value is what it is, the --bool and --bool-or-int options don't
>>>>> specify the value type, just how it is interpreted. For example: a value
>>>>> of '1' can be interpreted as 'true'.
>>>>
>>>> It is not really about "interpreting", but about showing, isn't it?
>>>
>>> Unless you are setting it, instead of reading it.
>>>
>>
>> I'd still suggest fixing the typo ("interpreted") and spelling out
>> "boolean".
>
> Oops! You mean s/intepreted/interpreted/?Yep :)
> > If we spell 'boolean' we might as well spell 'integer'; I think bool > and int are fine. >
"int" is at least a standard type name in C, whereas "bool" is not; but, yes, feel free to spell out "integer", or use "--int or --bool" as it is, which is a back reference to the corresponding entries for "--int" and "--bool", where things should be spelled out.
Michael
Felipe ContrerasRe: [PATCH 2/3] git config: clarify bool types
On Tue, Oct 13, 2009 at 10:09 AM, Michael J Gruber <git@drmicha.warpmail.net> wrote:
> Felipe Contreras venit, vidit, dixit 12.10.2009 19:14:
>> On Mon, Oct 12, 2009 at 3:30 PM, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>>> Felipe Contreras venit, vidit, dixit 12.10.2009 12:03:
>>>> On Mon, Oct 12, 2009 at 8:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>>>
>>>>>> The value is what it is, the --bool and --bool-or-int options don't
>>>>>> specify the value type, just how it is interpreted. For example: a value
>>>>>> of '1' can be interpreted as 'true'.
>>>>>
>>>>> It is not really about "interpreting", but about showing, isn't it?
>>>>
>>>> Unless you are setting it, instead of reading it.
>>>>
>>>
>>> I'd still suggest fixing the typo ("interpreted") and spelling out
>>> "boolean".
>>
>> Oops! You mean s/intepreted/interpreted/?
>
> Yep :)
>
>>
>> If we spell 'boolean' we might as well spell 'integer'; I think bool
>> and int are fine.
>>
>
> "int" is at least a standard type name in C, whereas "bool" is not; but,
> yes, feel free to spell out "integer", or use "--int or --bool" as it
> is, which is a back reference to the corresponding entries for "--int"
> and "--bool", where things should be spelled out.'bool' is also a standard type, in C99.
-- Felipe Contreras
Thiago FarinaRe: [PATCH 1/3] Fix a bunch of pointer declarations (codestyle)
Felipe Contreras <felipe.contreras@gmail.com> wrote: "Fix a bunch of pointer declarations".
But in this patch you fixed *only* one pointer declaration: struct diffstat_t* data -> struct diffstat_t *data
Felipe ContrerasRe: [PATCH 1/3] Fix a bunch of pointer declarations (codestyle)
On Sun, Oct 11, 2009 at 11:53 PM, Thiago Farina <tfransosi@gmail.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> wrote: > "Fix a bunch of pointer declarations". > > But in this patch you fixed *only* one pointer declaration: > struct diffstat_t* data -> struct diffstat_t *data
Yeah, it's a remainder of a patch I sent some time ago. I don't know why that didn't got picked up =/
-- Felipe Contreras