Skip to content

Commit

Permalink
Merge commit 'b319ef7' into jc/maint-fix-test-perm
Browse files Browse the repository at this point in the history
* commit 'b319ef7': (8132 commits)
  Add a small patch-mode testing library
  git-apply--interactive: Refactor patch mode code
  t8005: Nobody writes Russian in shift_jis
  Fix severe breakage in "git-apply --whitespace=fix"
  Update release notes for 1.6.4
  After renaming a section, print any trailing variable definitions
  Make section_name_match start on '[', and return the length on success
  send-email: detect cycles in alias expansion
  Show the presence of untracked files in the bash prompt.
  SunOS grep does not understand -C<n> nor -e
  Fix export_marks() error handling.
  git repack: keep commits hidden by a graft
  Add a test showing that 'git repack' throws away grafted-away parents
  git branch: clean up detached branch handling
  git branch: avoid unnecessary object lookups
  git branch: fix performance problem
  git svn: fix shallow clone when upstream revision is too new
  do_one_ref(): null_sha1 check is not about broken ref
  configure.ac: properly unset NEEDS_SSL_WITH_CRYPTO when sha1 func is missing
  janitor: useless checks before free
  ...
  • Loading branch information
Junio C Hamano committed Jan 31, 2010
2 parents b9b727d + b319ef7 commit 00d3278
Show file tree
Hide file tree
Showing 1,466 changed files with 223,615 additions and 52,971 deletions.
2 changes: 2 additions & 0 deletions .gitattributes
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@
* whitespace=!indent,trail,space
*.[ch] whitespace=indent,trail,space
39 changes: 25 additions & 14 deletions .gitignore
Original file line number Diff line number Diff line change
@@ -1,3 +1,4 @@
GIT-BUILD-OPTIONS
GIT-CFLAGS
GIT-GUI-VARS
GIT-VERSION-FILE
Expand All @@ -7,15 +8,15 @@ git-add--interactive
git-am
git-annotate
git-apply
git-applymbox
git-applypatch
git-archimport
git-archive
git-bisect
git-bisect--helper
git-blame
git-branch
git-bundle
git-cat-file
git-check-attr
git-check-ref-format
git-checkout
git-checkout-index
Expand All @@ -26,7 +27,6 @@ git-clone
git-commit
git-commit-tree
git-config
git-convert-objects
git-count-objects
git-cvsexportcommit
git-cvsimport
Expand All @@ -36,12 +36,15 @@ git-diff
git-diff-files
git-diff-index
git-diff-tree
git-difftool
git-difftool--helper
git-describe
git-fast-export
git-fast-import
git-fetch
git-fetch--tool
git-fetch-pack
git-findtags
git-filter-branch
git-fmt-merge-msg
git-for-each-ref
git-format-patch
Expand All @@ -51,14 +54,14 @@ git-gc
git-get-tar-commit-id
git-grep
git-hash-object
git-help
git-http-fetch
git-http-push
git-imap-send
git-index-pack
git-init
git-init-db
git-instaweb
git-local-fetch
git-log
git-lost-found
git-ls-files
Expand All @@ -76,9 +79,9 @@ git-merge-one-file
git-merge-ours
git-merge-recursive
git-merge-resolve
git-merge-stupid
git-merge-subtree
git-mergetool
git-mergetool--lib
git-mktag
git-mktree
git-name-rev
Expand All @@ -96,6 +99,7 @@ git-push
git-quiltimport
git-read-tree
git-rebase
git-rebase--interactive
git-receive-pack
git-reflog
git-relink
Expand All @@ -109,7 +113,6 @@ git-rev-list
git-rev-parse
git-revert
git-rm
git-runstatus
git-send-email
git-send-pack
git-sh-setup
Expand All @@ -119,14 +122,12 @@ git-show
git-show-branch
git-show-index
git-show-ref
git-ssh-fetch
git-ssh-pull
git-ssh-push
git-ssh-upload
git-stage
git-stash
git-status
git-stripspace
git-submodule
git-svn
git-svnimport
git-symbolic-ref
git-tag
git-tar-tree
Expand All @@ -140,23 +141,30 @@ git-upload-pack
git-var
git-verify-pack
git-verify-tag
git-web--browse
git-whatchanged
git-write-tree
git-core-*/?*
gitk-wish
gitweb/gitweb.cgi
test-chmtime
test-ctype
test-date
test-delta
test-dump-cache-tree
test-genrandom
test-match-trees
test-parse-options
test-path-utils
test-sha1
test-sigchain
common-cmds.h
*.tar.gz
*.dsc
*.deb
git-core.spec
git.spec
*.exe
*.[ao]
*.[aos]
*.py[co]
config.mak
autom4te.cache
Expand All @@ -166,3 +174,6 @@ config.status
config.mak.autogen
config.mak.append
configure
tags
TAGS
cscope*
26 changes: 25 additions & 1 deletion .mailmap
Original file line number Diff line number Diff line change
Expand Up @@ -5,36 +5,60 @@
# same person appearing not to be so.
#

Alexander Gavrilov <angavrilov@gmail.com>
Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Brian M. Carlson <sandals@crustytoothpaste.ath.cx>
Chris Shoemaker <c.shoemaker@cox.net>
Dana L. How <danahow@gmail.com>
Dana L. How <how@deathvalley.cswitch.com>
Daniel Barkalow <barkalow@iabervon.org>
David D. Kilzer <ddkilzer@kilzer.net>
David Kågedal <davidk@lysator.liu.se>
David S. Miller <davem@davemloft.net>
Dirk Süsserott <newsletter@dirk.my1.cc>
Fredrik Kuivinen <freku045@student.liu.se>
H. Peter Anvin <hpa@bonde.sc.orionmulti.com>
H. Peter Anvin <hpa@tazenda.sc.orionmulti.com>
H. Peter Anvin <hpa@trantor.hos.anvin.org>
Horst H. von Brand <vonbrand@inf.utfsm.cl>
İsmail Dönmez <ismail@pardus.org.tr>
Jay Soffian <jaysoffian+git@gmail.com>
Joachim Berdal Haga <cjhaga@fys.uio.no>
Jon Loeliger <jdl@freescale.com>
Jon Seymour <jon@blackcubes.dyndns.org>
Jonathan Nieder <jrnieder@uchicago.edu>
Junio C Hamano <junio@twinsun.com>
Karl Hasselström <kha@treskal.com>
Kent Engstrom <kent@lysator.liu.se>
Lars Doelle <lars.doelle@on-line.de>
Lars Doelle <lars.doelle@on-line ! de>
Lars Doelle <lars.doelle@on-line.de>
Li Hong <leehong@pku.edu.cn>
Lukas Sandström <lukass@etek.chalmers.se>
Martin Langhoff <martin@catalyst.net.nz>
Michael Coleman <tutufan@gmail.com>
Michael W. Olson <mwolson@gnu.org>
Michele Ballabio <barra_cuda@katamail.com>
Nanako Shiraishi <nanako3@bluebottle.com>
Nanako Shiraishi <nanako3@lavabit.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Philippe Bruhat <book@cpan.org>
Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
René Scharfe <rene.scharfe@lsrfire.ath.cx>
Robert Fitzsimons <robfitz@273k.net>
Sam Vilain <sam@vilain.net>
Santi Béjar <sbejar@gmail.com>
Sean Estabrooks <seanlkml@sympatico.ca>
Shawn O. Pearce <spearce@spearce.org>
Steven Grimm <koreth@midwinter.com>
Theodore Ts'o <tytso@mit.edu>
Tony Luck <tony.luck@intel.com>
Uwe Kleine-König <Uwe_Zeisberger@digi.com>
Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Uwe Kleine-König <uzeisberger@io.fsforth.de>
Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
Ville Skyttä <scop@xemacs.org>
William Pursell <bill.pursell@gmail.com>
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
anonymous <linux@horizon.com>
anonymous <linux@horizon.net>
1 change: 1 addition & 0 deletions Documentation/.gitattributes
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
*.txt whitespace
6 changes: 4 additions & 2 deletions Documentation/.gitignore
Original file line number Diff line number Diff line change
@@ -1,8 +1,10 @@
*.xml
*.html
*.1
*.7
*.[1-8]
*.made
*.texi
git.info
gitman.info
howto-index.txt
doc.dep
cmds-*.txt
134 changes: 134 additions & 0 deletions Documentation/CodingGuidelines
Original file line number Diff line number Diff line change
@@ -0,0 +1,134 @@
Like other projects, we also have some guidelines to keep to the
code. For git in general, three rough rules are:

- Most importantly, we never say "It's in POSIX; we'll happily
ignore your needs should your system not conform to it."
We live in the real world.

- However, we often say "Let's stay away from that construct,
it's not even in POSIX".

- In spite of the above two rules, we sometimes say "Although
this is not in POSIX, it (is so convenient | makes the code
much more readable | has other good characteristics) and
practically all the platforms we care about support it, so
let's use it".

Again, we live in the real world, and it is sometimes a
judgement call, the decision based more on real world
constraints people face than what the paper standard says.


As for more concrete guidelines, just imitate the existing code
(this is a good guideline, no matter which project you are
contributing to). It is always preferable to match the _local_
convention. New code added to git suite is expected to match
the overall style of existing code. Modifications to existing
code is expected to match the style the surrounding code already
uses (even if it doesn't match the overall style of existing code).

But if you must have a list of rules, here they are.

For shell scripts specifically (not exhaustive):

- We prefer $( ... ) for command substitution; unlike ``, it
properly nests. It should have been the way Bourne spelled
it from day one, but unfortunately isn't.

- We use ${parameter-word} and its [-=?+] siblings, and their
colon'ed "unset or null" form.

- We use ${parameter#word} and its [#%] siblings, and their
doubled "longest matching" form.

- We use Arithmetic Expansion $(( ... )).

- No "Substring Expansion" ${parameter:offset:length}.

- No shell arrays.

- No strlen ${#parameter}.

- No regexp ${parameter/pattern/string}.

- We do not use Process Substitution <(list) or >(list).

- We prefer "test" over "[ ... ]".

- We do not write the noiseword "function" in front of shell
functions.

- As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
[::], [==], nor [..]) for portability.

- We do not use \{m,n\};

- We do not use -E;

- We do not use ? nor + (which are \{0,1\} and \{1,\}
respectively in BRE) but that goes without saying as these
are ERE elements not BRE (note that \? and \+ are not even part
of BRE -- making them accessible from BRE is a GNU extension).

For C programs:

- We use tabs to indent, and interpret tabs as taking up to
8 spaces.

- We try to keep to at most 80 characters per line.

- When declaring pointers, the star sides with the variable
name, i.e. "char *string", not "char* string" or
"char * string". This makes it easier to understand code
like "char *string, c;".

- We avoid using braces unnecessarily. I.e.

if (bla) {
x = 1;
}

is frowned upon. A gray area is when the statement extends
over a few lines, and/or you have a lengthy comment atop of
it. Also, like in the Linux kernel, if there is a long list
of "else if" statements, it can make sense to add braces to
single line blocks.

- We try to avoid assignments inside if().

- Try to make your code understandable. You may put comments
in, but comments invariably tend to stale out when the code
they were describing changes. Often splitting a function
into two makes the intention of the code much clearer.

- Double negation is often harder to understand than no negation
at all.

- Some clever tricks, like using the !! operator with arithmetic
constructs, can be extremely confusing to others. Avoid them,
unless there is a compelling reason to use them.

- Use the API. No, really. We have a strbuf (variable length
string), several arrays with the ALLOC_GROW() macro, a
string_list for sorted string lists, a hash map (mapping struct
objects) named "struct decorate", amongst other things.

- When you come up with an API, document it.

- The first #include in C files, except in platform specific
compat/ implementations, should be git-compat-util.h or another
header file that includes it, such as cache.h or builtin.h.

- If you are planning a new command, consider writing it in shell
or perl first, so that changes in semantics can be easily
changed and discussed. Many git commands started out like
that, and a few are still scripts.

- Avoid introducing a new dependency into git. This means you
usually should stay away from scripting languages not already
used in the git core command set (unless your command is clearly
separate from it, such as an importer to convert random-scm-X
repositories to git).

- When we pass <string, length> pair to functions, we should try to
pass them in that order.
Loading

0 comments on commit 00d3278

Please sign in to comment.