# [PATCH] Fix capitalization of "renamelimit" in docs to agree with code 4 messages from 2011-12-19 to 2011-12-19. Participants: Pete Harlan, Jakub Narebski, Junio C Hamano. Thread: https://gitlist.dev/t/29204 ## Pete Harlan, 2011-12-19 00:34 Subject: [PATCH] Fix capitalization of "renamelimit" in docs to agree with code Message-ID: <4EEE86AC.2030802@pcharlan.com> URL: https://gitlist.dev/e/4EEE86AC.2030802%40pcharlan.com ``` Signed-off-by: Pete Harlan --- 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 -- ``` ## Jakub Narebski, 2011-12-19 00:51 Subject: Re: [PATCH] Fix capitalization of "renamelimit" in docs to agree with code Message-ID: URL: https://gitlist.dev/e/m3ty4xfkpc.fsf%40localhost.localdomain In-Reply-To: <4EEE86AC.2030802@pcharlan.com> ``` Pete Harlan writes: > Signed-off-by: Pete Harlan > --- > 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 ``` ## Junio C Hamano, 2011-12-19 01:02 Subject: Re: [PATCH] Fix capitalization of "renamelimit" in docs to agree with code Message-ID: <7vsjkhnzkt.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vsjkhnzkt.fsf%40alter.siamese.dyndns.org In-Reply-To: <4EEE86AC.2030802@pcharlan.com> ``` Pete Harlan writes: > Signed-off-by: Pete Harlan > --- > 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, 2011-12-19 01:13 Subject: Re: [PATCH] Fix capitalization of "renamelimit" in docs to agree with code Message-ID: <4EEE8FB3.7070206@pcharlan.com> URL: https://gitlist.dev/e/4EEE8FB3.7070206%40pcharlan.com In-Reply-To: <7vsjkhnzkt.fsf@alter.siamese.dyndns.org> ``` On 12/18/2011 05:02 PM, Junio C Hamano wrote: > Pete Harlan writes: > >> Signed-off-by: Pete Harlan >> --- >> 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. ```