Consensus on "Git"

Hi folks,

Is there consensus on "Git" being the standard capitalisation, versus "GIT"? I only really see "git" and "Git" on the mailing list and in most external documentation and websites (e.g. git-scm.com and github.com), but git's source tells a different picture:

$ cat *.[ch] | egrep -o '\bG[Ii][Tt]\b' | sort | uniq -c
  36 GIT
   7 Git
$ cat Documentation/* 2> /dev/null | egrep -o '\bG[Ii][Tt]\b' | sort | uniq -c
 284 GIT
 155 Git

Dave.

Heya,

On Wed, Nov 11, 2009 at 09:32, David Symonds <dsymonds@gmail.com> wrote:

Definitely "Git" or "git", the source code ones are probably from variable names, something like "GIT_INSTALL_DIR" and whatnot.

David Symonds <dsymonds@gmail.com> writes:

I am not a consensus, but from day 1, Linus talked about "git" (all lowercase) and "Git" was used only when it came at the beginning of a sentence (an usual English capitalization rule) or in a section or book title where all words (except prepositions such as "in", "on") are capitalized, and I try to mimick it myself for consistency.

As a corollary, unless I spell all the other words in capital to SHOUT, I never write GIT.

On Wed, Nov 11, 2009 at 01:06:44AM -0800, Junio C Hamano wrote:

Except for the title of every set of release notes, which all start with:

  GIT vX.Y.Z Release Notes

? :)

For a fun (ab)use of blame, you can see who wrote each of David's suspect lines with:

   git grep -n "\bGIT\b" |
   while IFS=: read file line junk; do
     git blame -f -L $line,$line $file
   done |
   less

Many of them are variables (e.g., \b gets rid of "_", but we still have "-", so GIT-VERSION and such are still there). Many others are the title of the "GIT" section of the manpages. But there are some legitimate uses, too. Many of them blame to quite a long time ago, though (e.g., Documentation/everyday.txt has two uses by you in 2005).

-Peff

Jeff King <peff@peff.net> writes:

Yeah these were copied from release to release and I do not pay much attention to the minute details of how my tools I wrote long time ago spells things ;-)

Perhaps I should update my scripts to generate them.

On Wed, Nov 11, 2009 at 04:27:31AM -0500, Jeff King wrote:

BTW, here is a much better grep (still a few false positives, but most lines are meanginful):

   git grep -n -E "(^|[^A-Z_-])GIT($|[^A-Z_-])" |
   grep -v ':GIT$' |
   while IFS=: read file line junk; do
     git blame -f -L $line,$line $file
   done |
   less

You can really see that most of the uses of GIT are ancient. I wonder if we should downcase the few that are in user-visible error messages. I will let somebody else spend their time on such a conversion if they want, though. I've already spent enough on this. :)

-Peff

2009/11/11 David Symonds <dsymonds@gmail.com>:

All upper case in the sources and documentation will mean that it is either an environment variable (e.g. GIT_INSTALL_DIR as Sverre has noted), and for preprocessor constants/definitions.

However, those are not what you are searching for. I.e.

$ grep -P '\bGIT\b' *.[ch] builtin-apply.c: * We have read "GIT binary patch\n"; what follows is a line builtin-apply.c: static const char git_binary[] = "GIT binary patch\n"; builtin-cat-file.c: * GIT - The information manager from hell builtin-check-ref-format.c: * GIT - The information manager from hell builtin-commit-tree.c: * GIT - The information manager from hell builtin-diff-files.c: * GIT - The information manager from hell builtin-init-db.c: * GIT - The information manager from hell builtin-ls-tree.c: * GIT - The information manager from hell builtin-mktree.c: * GIT - the stupid content tracker builtin-read-tree.c: * GIT - The information manager from hell builtin-update-index.c: * GIT - The information manager from hell builtin-write-tree.c: * GIT - The information manager from hell config.c: * GIT - The information manager from hell date.c: * GIT - The information manager from hell diff.c: fprintf(file, "GIT binary patch\n"); diff-delta.c: * Rewritten for GIT by Nicolas Pitre <nico@fluxnic.net>, (C) 2005-2007 fast-import.c: # GIT does not permit ':' in ref or tag strings. fast-import.c: path ::= # GIT style file path, e.g. "a/b/c"; fast-import.c: ref ::= # GIT ref name, e.g. "refs/heads/MOZ_GECKO_EXPERIMENT"; fast-import.c: tag ::= # GIT tag name, e.g. "FIREFOX_1_5"; fast-import.c: sha1exp ::= # Any valid GIT SHA1 expression; fast-import.c: name ::= # valid GIT author/committer name; fast-import.c: email ::= # valid GIT author/committer email; fast-import.c: tz ::= # GIT style timezone; fast-import.c: die("Branch name doesn't conform to GIT standards: %s", name); hash-object.c: * GIT - The information manager from hell progress.c: * Simple text-based progress display module for GIT read-cache.c: * GIT - The information manager from hell read-cache.c: * cache, ie the parts that aren't tracked by GIT, and only used sha1_file.c: * GIT - The information manager from hell sha1_file.c: " (try upgrading GIT to a newer version)", sha1_file.c: return error("file %s is not a GIT packfile", p->pack_name); sha1_file.c: " supported (try upgrading GIT to a newer version)", trace.c: * GIT - The information manager from hell usage.c: * GIT - The information manager from hell var.c: * GIT - The information manager from hell

And selected extracts from:

$ grep -P '\bGIT\b' Documentation/* Documentation/asciidoc.conf:# Show GIT link as: <command>(<section>); if section is defined, else just show Documentation/everyday.txt:Everyday GIT With 20 Commands Or So Documentation/everyday.txt:My typical GIT day.:: Documentation/git-tools.txt: providing generally smoother user experience than the "raw" Core GIT Documentation/git-tools.txt: is now in core GIT. Documentation/git-tools.txt: pg is a shell script wrapper around GIT to help the user manage a set of Documentation/git-tools.txt: Stacked GIT provides a quilt-like patch management functionality in the Documentation/git-tools.txt: GIT environment. You can easily manage your patches in the scope of GIT Documentation/git-tools.txt: gitk is a simple Tk GUI for browsing history of GIT repositories easily. Documentation/git-tools.txt: GITweb provides full-fledged web interface for GIT repositories. Documentation/git-tag.txt:GIT Documentation/RelNotes-1.6.1.txt:GIT v1.6.1 Release Notes

- Reece

Hi,

On Wed, 11 Nov 2009, David Symonds wrote:

There is definitely no consensus.

Personally, I started to capitalize it as a reaction to business types (apparently you have to turn in your sense of humor when you get an MBA), who were not happy with the abbreviation "global information tracker" (which would merit an all-capitalization a la CVS) [*1*], let alone with the connotation as a British slang word.

Yes, in Open Source, we are used to crude, geeky humor, some of us even accept blunt mails, but we are embedded in a world that is called "reality".

In my experience, in this world it is much easier to tell people that your program is called "Git" ("could have been John, either") and be done with the questions.

Ciao, Dscho

Footnote *1*: I tried once to reinterpret GIT as meaning "Git Is Terrific", but that did not fly too well. :-)

On 2009-11-11 10:33 (+0100), Johannes Schindelin wrote:

Yes, that’s how the language works. Proper nouns are capitalized, so in plain text the name of this program should always be written “Git”. Only in command examples it is “git”.

Sometimes people mix proper nouns and logos/brands. Proper nouns are under the rules of the language. For example, I can’t go telling people that my name must be written “teEMu” because I don’t own Finnish.

In logos the brands’ owner can try to be funny and cool and different and write anything they want (like “gɨT” or “GīT”).

Teemu Likonen venit, vidit, dixit 11.11.2009 15:58:

And why Dick Cheney was allowed to keep his name ;)

Given that reasoning, we should really use "Git" whenever the program or project name is meant. Is that something we can reach concensus on?

Nice!

Michael