Pete Harlan [off-list ref] writes:
Signed-off-by: Pete Harlan <redacted>
---
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.
On 12/18/2011 05:02 PM, Junio C Hamano wrote:
Pete Harlan [off-list ref] writes:
quoted
Signed-off-by: Pete Harlan <redacted>
---
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.