[PATCH] Fix capitalization of "renamelimit" in docs to agree with code

[PATCH] Fix capitalization of "renamelimit" in docs to agree with code

[Pete Harlan]

Signed-off-by: Pete Harlan <pgit@pcharlan.com>
---
The documentation and bash-completion have always capitalized
"renamelimit" as "renameLimit".  The code has always lowercased the
whole name.  Repair the docs.

 Documentation/diff-config.txt          |    2 +-
 Documentation/merge-config.txt         |    4 ++--
 contrib/completion/git-completion.bash |    4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index 1aed79e..1b9a314 100644
--- a/Documentation/diff-config.txt
+++ b/Documentation/diff-config.txt
@@ -86,7 +86,7 @@ diff.mnemonicprefix::
 diff.noprefix::
 	If set, 'git diff' does not show any source or destination prefix.

-diff.renameLimit::
+diff.renamelimit::
 	The number of files to consider when performing the copy/rename
 	detection; equivalent to the 'git diff' option '-l'.

diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt
index 861bd6f..fdb3cb6 100644
--- a/Documentation/merge-config.txt
+++ b/Documentation/merge-config.txt
@@ -32,10 +32,10 @@ merge.log::
 	actual commits that are being merged.  Defaults to false, and
 	true is a synonym for 20.

-merge.renameLimit::
+merge.renamelimit::
 	The number of files to consider when performing rename detection
 	during a merge; if not specified, defaults to the value of
-	diff.renameLimit.
+	diff.renamelimit.

 merge.renormalize::
 	Tell git that canonical representation of files in the
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index cc1bdf9..76f66e1 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2122,7 +2122,7 @@ _git_config ()
 		diff.ignoreSubmodules
 		diff.mnemonicprefix
 		diff.noprefix
-		diff.renameLimit
+		diff.renamelimit
 		diff.renames
 		diff.suppressBlankEmpty
 		diff.tool
@@ -2218,7 +2218,7 @@ _git_config ()
 		merge.
 		merge.conflictstyle
 		merge.log
-		merge.renameLimit
+		merge.renamelimit
 		merge.renormalize
 		merge.stat
 		merge.tool
-- 

Re: [PATCH] Fix capitalization of "renamelimit" in docs to agree with code

[Jakub Narebski]

Pete Harlan <pgit@pcharlan.com> writes:

> Signed-off-by: Pete Harlan <pgit@pcharlan.com>
> ---
> The documentation and bash-completion have always capitalized
> "renamelimit" as "renameLimit".  The code has always lowercased the
> whole name.  Repair the docs.

Key names are *case insensitive* so we can write it in docs in a way
that is more clear, like 'renameLimit'.

Code compares with lowercased key name, so that is why it uses
'renamelimit'.

> @@ -2122,7 +2122,7 @@ _git_config ()
>  		diff.ignoreSubmodules
>  		diff.mnemonicprefix
>  		diff.noprefix
> -		diff.renameLimit
> +		diff.renamelimit
>  		diff.renames
>  		diff.suppressBlankEmpty
>  		diff.tool

Consitency - why you change diff.renameLimit but not
diff.ignoreSubmodules?

-- 
Jakub Narebski

Re: [PATCH] Fix capitalization of "renamelimit" in docs to agree with code

[Junio C Hamano]

Pete Harlan <pgit@pcharlan.com> writes:

> Signed-off-by: Pete Harlan <pgit@pcharlan.com>
> ---
> The documentation and bash-completion have always capitalized
> "renamelimit" as "renameLimit".  The code has always lowercased the
> whole name.  Repair the docs.

Please don't do this.

Exactly because we treat the variable name part (and the top-level section
part of three-part names) case insensitively, the code lowercases before
comparing as an implementation detail.

However, you will be naming the same variable whether you spell it using
all lowercase, or using camelCase (i.e. it does not really matter what
case the user uses). The camelCase makes it slightly easier to see where
the word boundaries are than alllowercase, and that is why we try to use
it in our documentes, which is after all meant to be read by humans.

I would also appreciate if people tried not to overflow my mailbox with an
incorrect patch that hasn't been discussed and hasn't seen concensus on
the list that the particular change is a good thing to do, unless the
patch is about an area that I am an area expert (you can see who the area
experts are by asking "git shortlog --no-merges -n" or "git blame").

Thanks.

Re: [PATCH] Fix capitalization of "renamelimit" in docs to agree with code

[Pete Harlan]

On 12/18/2011 05:02 PM, Junio C Hamano wrote:
> Pete Harlan <pgit@pcharlan.com> writes:
> 
>> Signed-off-by: Pete Harlan <pgit@pcharlan.com>
>> ---
>> The documentation and bash-completion have always capitalized
>> "renamelimit" as "renameLimit".  The code has always lowercased the
>> whole name.  Repair the docs.
> 
> Please don't do this.

Sorry for the spam.  There was a circumstance at work where it appeared
clear that case wasn't being ignored and it bit us twice.  Obviously our
problem lies elsewhere; please forgive the intrusion.

SubmittingPatches says to send to you directly if (and only if) the
patch is ready for inclusion.  Next time I won't presume that a patch is
ready without review however obvious that may seem to me at the time.

--Pete

> Exactly because we treat the variable name part (and the top-level section
> part of three-part names) case insensitively, the code lowercases before
> comparing as an implementation detail.
> 
> However, you will be naming the same variable whether you spell it using
> all lowercase, or using camelCase (i.e. it does not really matter what
> case the user uses). The camelCase makes it slightly easier to see where
> the word boundaries are than alllowercase, and that is why we try to use
> it in our documentes, which is after all meant to be read by humans.
> 
> I would also appreciate if people tried not to overflow my mailbox with an
> incorrect patch that hasn't been discussed and hasn't seen concensus on
> the list that the particular change is a good thing to do, unless the
> patch is about an area that I am an area expert (you can see who the area
> experts are by asking "git shortlog --no-merges -n" or "git blame").
> 
> Thanks.