From: Reece Dunn <msclrhd@googlemail.com>
To: David Symonds <dsymonds@gmail.com>
Cc: git <git@vger.kernel.org>
Subject: Re: Consensus on "Git"
Date: Wed, 11 Nov 2009 09:21:26 +0000 [thread overview]
Message-ID: <3f4fd2640911110121y17f0d78boadf803502e04475d@mail.gmail.com> (raw)
In-Reply-To: <ee77f5c20911110032r65a60653sfeef34e3de07d17e@mail.gmail.com>
2009/11/11 David Symonds <dsymonds@gmail.com>:
> 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
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
next prev parent reply other threads:[~2009-11-11 9:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-11 8:32 Consensus on "Git" David Symonds
2009-11-11 9:02 ` Sverre Rabbelier
2009-11-11 9:06 ` Junio C Hamano
2009-11-11 9:27 ` Jeff King
2009-11-11 9:36 ` Junio C Hamano
2009-11-11 9:36 ` Jeff King
2009-11-11 9:21 ` Reece Dunn [this message]
2009-11-11 9:33 ` Johannes Schindelin
2009-11-11 14:58 ` Teemu Likonen
2009-11-11 15:37 ` Michael J Gruber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3f4fd2640911110121y17f0d78boadf803502e04475d@mail.gmail.com \
--to=msclrhd@googlemail.com \
--cc=dsymonds@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).