[PATCH 0/3] Trivial patches

[PATCH 0/3] Trivial patches

[Felipe Contreras]

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(-)

[PATCH 1/3] Fix a bunch of pointer declarations (codestyle)

[Felipe Contreras]

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

[PATCH 2/3] git config: clarify bool types

[Felipe Contreras]

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'.

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

[PATCH 3/3] user-manual: use 'fast-forward'

[Felipe Contreras]

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

Re: [PATCH 1/3] Fix a bunch of pointer declarations (codestyle)

[Thiago Farina]

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

Re: [PATCH 1/3] Fix a bunch of pointer declarations (codestyle)

[Felipe Contreras]

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

Re: [PATCH 2/3] git config: clarify bool types

[Junio C Hamano]

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 = 0

you would see

    $ git config --bool-or-int core.repositoryformatversion
    0
    $ git config --bool core.repositoryformatversion
    false
    $ git config --int core.repositoryformatversion
    0

So it would be more like...

	show value as boolean
        show value as integer or boolean
        show value as integer

wouldn'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.g31fc3

Re: [PATCH 3/3] user-manual: use 'fast-forward'

[Junio C Hamano]

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?

Re: [PATCH 2/3] git config: clarify bool types

[Felipe Contreras]

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

Re: [PATCH 3/3] user-manual: use 'fast-forward'

[Felipe Contreras]

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

Re: [PATCH 2/3] git config: clarify bool types

[Michael J Gruber]

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

Re: [PATCH 3/3] user-manual: use 'fast-forward'

[Michael J Gruber]

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

Re: [PATCH 2/3] git config: clarify bool types

[Felipe Contreras]

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

Re: [PATCH 2/3] git config: clarify bool types

[Michael J Gruber]

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

Re: [PATCH 2/3] git config: clarify bool types

[Felipe Contreras]

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