threads / patch / 29204

patchFix capitalization of "renamelimit" in docs to agree with code

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

## tl;dr

4 messages between Dec 19, 2011 and Dec 19, 2011. Diffs are folded; open one to read it.

replies: 3people: 3as markdown or json

Pete Harlan· Dec 19, 2011, 00:34 UTC · lore
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(-)
Show changes to 3 files +5 −5

Documentation/diff-config.txt, Documentation/merge-config.txt, contrib/completion/git-completion.bash

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
Jakub Narebski· Dec 19, 2011, 00:51 UTC · re: Pete Harlan · lore

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

Pete Harlan <pgit@pcharlan.com> writes:
Show 5 quoted lines
> 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'.

Show 9 quoted lines
> @@ -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
Junio C Hamano· Dec 19, 2011, 01:02 UTC · re: Pete Harlan · lore

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

Pete Harlan <pgit@pcharlan.com> writes:
Show 5 quoted lines
> 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.
Pete Harlan· Dec 19, 2011, 01:13 UTC · re: Junio C Hamano · lore

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

On 12/18/2011 05:02 PM, Junio C Hamano wrote:
Show 9 quoted lines
> 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
Show 17 quoted lines
> 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.

← back to recent threads