Fix capitalization of "renamelimit" in docs to agree with code
PATCH 1/1 Fix capitalization of "renamelimit" in docs to agree with code
---
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(-)
Documentation/diff-config.txt +1 -1
@@ -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'.
Documentation/merge-config.txt +2 -2
@@ -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
(quoted diff) +0 -0
b/contrib/completion/git-completion.bash
index cc1bdf9..76f66e1 100755
contrib/completion/git-completion.bash +2 -2
@@ -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
Quoted 5 lines · Pete Harlan
Signed-off-by Pete Harlan <[email protected]>---
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.
Quoted 9 lines · Junio C Hamano
Quoted 5 lines · Pete Harlan
Signed-off-by Pete Harlan <[email protected]>---
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
Quoted 17 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.
Quoted 5 lines · Pete Harlan
Signed-off-by Pete Harlan <[email protected]>---
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'.
contrib/completion/git-completion.bash _git_config () · line 2128
Quoted 9 lines
contrib/completion/git-completion.bash +1
-1@@ -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?
Signature · 1 line
Jakub Narebski