Commit a6080a0a authored by Junio C Hamano's avatar Junio C Hamano

War on whitespace

This uses "git-apply --whitespace=strip" to fix whitespace errors that have
crept in to our source files over time.  There are a few files that need
to have trailing whitespaces (most notably, test vectors).  The results
still passes the test, and build result in Documentation/ area is unchanged.
Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
parent d44c782b
......@@ -20,5 +20,3 @@ Fixes since v1.5.0.3
* Documentation updates
* User manual updates
......@@ -24,5 +24,3 @@ Fixes since v1.5.0.3
* Documentation updates
* User manual updates
......@@ -19,4 +19,3 @@ Fixes since v1.5.0.5
- user-manual has better cross references.
- gitweb installation/deployment procedure is now documented.
......@@ -43,4 +43,3 @@ Fixes since v1.5.1.2
description was given by the caller.
Also contains various documentation updates.
......@@ -296,15 +296,15 @@ diff --git a/pico/pico.c b/pico/pico.c
--- a/pico/pico.c
+++ b/pico/pico.c
@@ -219,7 +219,9 @@ PICO *pm;
switch(pico_all_done){ /* prepare for/handle final events */
case COMP_EXIT : /* already confirmed */
packheader();
switch(pico_all_done){ /* prepare for/handle final events */
case COMP_EXIT : /* already confirmed */
packheader();
+#if 0
stripwhitespace();
stripwhitespace();
+#endif
c |= COMP_EXIT;
break;
c |= COMP_EXIT;
break;
(Daniel Barkalow)
......
......@@ -54,5 +54,3 @@ ifdef::backend-xhtml11[]
[gitlink-inlinemacro]
<a href="{target}.html">{target}{0?({0})}</a>
endif::backend-xhtml11[]
......@@ -682,5 +682,3 @@ receive.denyNonFastForwards::
transfer.unpackLimit::
When `fetch.unpackLimit` or `receive.unpackLimit` are
not set, the value of this variable is used instead.
......@@ -9,11 +9,11 @@ repository, mainly because being hands-on and using explicit examples is
often the best way of explaining what is going on.
In normal life, most people wouldn't use the "core" git programs
directly, but rather script around them to make them more palatable.
directly, but rather script around them to make them more palatable.
Understanding the core git stuff may help some people get those scripts
done, though, and it may also be instructive in helping people
understand what it is that the higher-level helper scripts are actually
doing.
doing.
The core git is often called "plumbing", with the prettier user
interfaces on top of it called "porcelain". You may not want to use the
......@@ -41,7 +41,7 @@ Creating a new git repository couldn't be easier: all git repositories start
out empty, and the only thing you need to do is find yourself a
subdirectory that you want to use as a working tree - either an empty
one for a totally new project, or an existing working tree that you want
to import into git.
to import into git.
For our first example, we're going to start a totally new repository from
scratch, with no pre-existing files, and we'll call it `git-tutorial`.
......@@ -169,7 +169,7 @@ $ ls .git/objects/??/*
and see two files:
----------------
.git/objects/55/7db03de997c86a4a028e1ebd3a1ceb225be238
.git/objects/55/7db03de997c86a4a028e1ebd3a1ceb225be238
.git/objects/f2/4c74a2e500f5ee1332c86b94199f52b1d1d962
----------------
......@@ -220,7 +220,7 @@ you have not actually really "checked in" your files into git so far,
you've only *told* git about them.
However, since git knows about them, you can now start using some of the
most basic git commands to manipulate the files or look at their status.
most basic git commands to manipulate the files or look at their status.
In particular, let's not even check in the two files into git yet, we'll
start off by adding another line to `hello` first:
......@@ -350,7 +350,7 @@ Making a change
Remember how we did the `git-update-index` on file `hello` and then we
changed `hello` afterward, and could compare the new state of `hello` with the
state we saved in the index file?
state we saved in the index file?
Further, remember how I said that `git-write-tree` writes the contents
of the *index* file to the tree, and thus what we just committed was in
......@@ -370,7 +370,7 @@ file and the working tree, `git-diff-index` shows the differences
between a committed *tree* and either the index file or the working
tree. In other words, `git-diff-index` wants a tree to be diffed
against, and before we did the commit, we couldn't do that, because we
didn't have anything to diff against.
didn't have anything to diff against.
But now we can do
......@@ -379,7 +379,7 @@ $ git-diff-index -p HEAD
----------------
(where `-p` has the same meaning as it did in `git-diff-files`), and it
will show us the same difference, but for a totally different reason.
will show us the same difference, but for a totally different reason.
Now we're comparing the working tree not against the index file,
but against the tree we just wrote. It just so happens that those two
are obviously the same, so we get the same result.
......@@ -398,7 +398,7 @@ working tree, but when given the `\--cached` flag, it is told to
instead compare against just the index cache contents, and ignore the
current working tree state entirely. Since we just wrote the index
file to HEAD, doing `git-diff-index \--cached -p HEAD` should thus return
an empty set of differences, and that's exactly what it does.
an empty set of differences, and that's exactly what it does.
[NOTE]
================
......@@ -549,7 +549,7 @@ $ git-whatchanged -p --root
----------------
and you will see exactly what has changed in the repository over its
short history.
short history.
[NOTE]
The `\--root` flag is a flag to `git-diff-tree` to tell it to
......@@ -637,7 +637,7 @@ So the mental model of "the git information is always tied directly to
the working tree that it describes" may not be technically 100%
accurate, but it's a good model for all normal use.
This has two implications:
This has two implications:
- if you grow bored with the tutorial repository you created (or you've
made a mistake and want to start all over), you can just do simple
......@@ -705,7 +705,7 @@ Many (most?) public remote repositories will not contain any of
the checked out files or even an index file, and will *only* contain the
actual core git files. Such a repository usually doesn't even have the
`.git` subdirectory, but has all the git files directly in the
repository.
repository.
To create your own local live copy of such a "raw" git repository, you'd
first create your own subdirectory for the project, and then copy the
......@@ -718,7 +718,7 @@ $ cd my-git
$ rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ .git
----------------
followed by
followed by
----------------
$ git-read-tree HEAD
......@@ -738,7 +738,7 @@ up-to-date (so that you don't have to refresh it afterward), and the
`-a` flag means "check out all files" (if you have a stale copy or an
older version of a checked out tree you may also need to add the `-f`
flag first, to tell git-checkout-index to *force* overwriting of any old
files).
files).
Again, this can all be simplified with
......@@ -751,7 +751,7 @@ $ git checkout
which will end up doing all of the above for you.
You have now successfully copied somebody else's (mine) remote
repository, and checked it out.
repository, and checked it out.
Creating a new branch
......@@ -760,14 +760,14 @@ Creating a new branch
Branches in git are really nothing more than pointers into the git
object database from within the `.git/refs/` subdirectory, and as we
already discussed, the `HEAD` branch is nothing but a symlink to one of
these object pointers.
these object pointers.
You can at any time create a new branch by just picking an arbitrary
point in the project history, and just writing the SHA1 name of that
object into a file under `.git/refs/heads/`. You can use any filename you
want (and indeed, subdirectories), but the convention is that the
"normal" branch is called `master`. That's just a convention, though,
and nothing enforces it.
and nothing enforces it.
To show that as an example, let's go back to the git-tutorial repository we
used earlier, and create a branch in it. You do that by simply just
......@@ -778,7 +778,7 @@ $ git checkout -b mybranch
------------
will create a new branch based at the current `HEAD` position, and switch
to it.
to it.
[NOTE]
================================================
......@@ -825,7 +825,7 @@ checking it out and switching to it. If so, just use the command
$ git branch <branchname> [startingpoint]
------------
which will simply _create_ the branch, but will not do anything further.
which will simply _create_ the branch, but will not do anything further.
You can then later -- once you decide that you want to actually develop
on that branch -- switch to that branch with a regular `git checkout`
with the branchname as the argument.
......@@ -884,7 +884,7 @@ $ gitk --all
will show you graphically both of your branches (that's what the `\--all`
means: normally it will just show you your current `HEAD`) and their
histories. You can also see exactly how they came to be from a common
source.
source.
Anyway, let's exit `gitk` (`^Q` or the File menu), and decide that we want
to merge the work we did on the `mybranch` branch into the `master`
......@@ -905,8 +905,8 @@ of it as it can automatically (which in this case is just merge the `example`
file, which had no differences in the `mybranch` branch), and say:
----------------
Auto-merging hello
CONFLICT (content): Merge conflict in hello
Auto-merging hello
CONFLICT (content): Merge conflict in hello
Automatic merge failed; fix up by hand
----------------
......@@ -1387,7 +1387,7 @@ repository. Kernel.org mirror network takes care of the
propagation to other publicly visible machines:
------------
$ git push master.kernel.org:/pub/scm/git/git.git/
$ git push master.kernel.org:/pub/scm/git/git.git/
------------
......
The output format from "git-diff-index", "git-diff-tree" and
"git-diff-files" are very similar.
These commands all compare two sets of things; what is
These commands all compare two sets of things; what is
compared differs:
git-diff-index <tree-ish>::
......@@ -139,28 +139,28 @@ index fabadb8,cc95eb0..4866510
--- a/describe.c
+++ b/describe.c
@@@ -98,20 -98,12 +98,20 @@@
return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
}
- static void describe(char *arg)
-static void describe(struct commit *cmit, int last_one)
++static void describe(char *arg, int last_one)
{
+ unsigned char sha1[20];
+ struct commit *cmit;
struct commit_list *list;
static int initialized = 0;
struct commit_name *n;
struct commit_list *list;
static int initialized = 0;
struct commit_name *n;
+ if (get_sha1(arg, sha1) < 0)
+ usage(describe_usage);
+ cmit = lookup_commit_reference(sha1);
+ if (!cmit)
+ usage(describe_usage);
+
if (!initialized) {
initialized = 1;
for_each_ref(get_name);
if (!initialized) {
initialized = 1;
for_each_ref(get_name);
------------
1. It is preceded with a "git diff" header, that looks like
......@@ -233,4 +233,3 @@ parents). When shown by `git diff-files -c`, it compares the
two unresolved merge parents with the working tree file
(i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka
"their version").
......@@ -100,8 +100,8 @@
that matches other criteria, nothing is selected.
--find-copies-harder::
For performance reasons, by default, -C option finds copies only
if the original file of the copy was modified in the same
For performance reasons, by default, -C option finds copies only
if the original file of the copy was modified in the same
changeset. This flag makes the command
inspect unmodified files as candidates for the source of
copy. This is a very expensive operation for large
......
......@@ -71,7 +71,7 @@ The first transformation in the chain is diffcore-pathspec, and
is controlled by giving the pathname parameters to the
git-diff-* commands on the command line. The pathspec is used
to limit the world diff operates in. It removes the filepairs
outside the specified set of pathnames. E.g. If the input set
outside the specified set of pathnames. E.g. If the input set
of filepairs included:
------------------------------------------------
......@@ -269,4 +269,3 @@ Documentation
*.c
t
------------------------------------------------
/*
CSS stylesheet for XHTML produced by DocBook XSL stylesheets.
Tested with XSL stylesheets 1.61.2, 1.67.2
*/
span.strong {
font-weight: bold;
}
body blockquote {
margin-top: .75em;
line-height: 1.5;
margin-bottom: .75em;
}
html body {
margin: 1em 5% 1em 5%;
line-height: 1.2;
}
body div {
margin: 0;
}
h1, h2, h3, h4, h5, h6,
div.toc p b,
div.list-of-figures p b,
div.list-of-tables p b,
div.abstract p.title
{
color: #527bbd;
font-family: tahoma, verdana, sans-serif;
}
div.toc p:first-child,
div.list-of-figures p:first-child,
div.list-of-tables p:first-child,
div.example p.title
{
margin-bottom: 0.2em;
}
body h1 {
margin: .0em 0 0 -4%;
line-height: 1.3;
border-bottom: 2px solid silver;
}
body h2 {
margin: 0.5em 0 0 -4%;
line-height: 1.3;
border-bottom: 2px solid silver;
}
body h3 {
margin: .8em 0 0 -3%;
line-height: 1.3;
}
body h4 {
margin: .8em 0 0 -3%;
line-height: 1.3;
}
body h5 {
margin: .8em 0 0 -2%;
line-height: 1.3;
}
body h6 {
margin: .8em 0 0 -1%;
line-height: 1.3;
}
body hr {
border: none; /* Broken on IE6 */
}
div.footnotes hr {
border: 1px solid silver;
}
div.navheader th, div.navheader td, div.navfooter td {
font-family: sans-serif;
font-size: 0.9em;
font-weight: bold;
color: #527bbd;
}
div.navheader img, div.navfooter img {
border-style: none;
}
div.navheader a, div.navfooter a {
font-weight: normal;
}
div.navfooter hr {
border: 1px solid silver;
}
body td {
line-height: 1.2
}
body th {
line-height: 1.2;
}
ol {
line-height: 1.2;
}
ul, body dir, body menu {
line-height: 1.2;
}
html {
margin: 0;
padding: 0;
}
body h1, body h2, body h3, body h4, body h5, body h6 {
margin-left: 0
}
body pre {
margin: 0.5em 10% 0.5em 1em;
line-height: 1.0;
color: navy;
}
tt.literal, code.literal {
color: navy;
}
div.literallayout p {
padding: 0em;
margin: 0em;
}
div.literallayout {
font-family: monospace;
# margin: 0.5em 10% 0.5em 1em;
margin: 0em;
color: navy;
border: 1px solid silver;
background: #f4f4f4;
padding: 0.5em;
}
.programlisting, .screen {
border: 1px solid silver;
background: #f4f4f4;
margin: 0.5em 10% 0.5em 0;
padding: 0.5em 1em;
}
div.sidebar {
background: #ffffee;
margin: 1.0em 10% 0.5em 0;
padding: 0.5em 1em;
border: 1px solid silver;
}
div.sidebar * { padding: 0; }
div.sidebar div { margin: 0; }
div.sidebar p.title {
font-family: sans-serif;
margin-top: 0.5em;
margin-bottom: 0.2em;
}
div.bibliomixed {
margin: 0.5em 5% 0.5em 1em;
}
div.glossary dt {
font-weight: bold;
}
div.glossary dd p {
margin-top: 0.2em;
}
dl {
margin: .8em 0;
line-height: 1.2;
}
dt {
margin-top: 0.5em;
}
dt span.term {
font-style: italic;
}
div.variablelist dd p {
margin-top: 0;
}
div.itemizedlist li, div.orderedlist li {
margin-left: -0.8em;
margin-top: 0.5em;
}
ul, ol {
list-style-position: outside;
}
div.sidebar ul, div.sidebar ol {
margin-left: 2.8em;
}
div.itemizedlist p.title,
div.orderedlist p.title,
div.variablelist p.title
{
margin-bottom: -0.8em;
}
div.revhistory table {
border-collapse: collapse;
border: none;
}
div.revhistory th {
border: none;
color: #527bbd;
font-family: tahoma, verdana, sans-serif;
}
div.revhistory td {
border: 1px solid silver;
}
/* Keep TOC and index lines close together. */
div.toc dl, div.toc dt,
div.list-of-figures dl, div.list-of-figures dt,
div.list-of-tables dl, div.list-of-tables dt,
div.indexdiv dl, div.indexdiv dt
{
line-height: normal;
margin-top: 0;
margin-bottom: 0;
}
/*
Table styling does not work because of overriding attributes in
generated HTML.
*/
div.table table,
div.informaltable table
{
margin-left: 0;
margin-right: 5%;
margin-bottom: 0.8em;
}
div.informaltable table
{
margin-top: 0.4em
}
div.table thead,
div.table tfoot,
div.table tbody,
div.informaltable thead,
div.informaltable tfoot,
div.informaltable tbody
{
/* No effect in IE6. */
border-top: 2px solid #527bbd;
border-bottom: 2px solid #527bbd;
}
div.table thead, div.table tfoot,
div.informaltable thead, div.informaltable tfoot
{
font-weight: bold;
}
div.mediaobject img {
border: 1px solid silver;
margin-bottom: 0.8em;
}
div.figure p.title,
div.table p.title
{
margin-top: 1em;
margin-bottom: 0.4em;
}
@media print {
div.navheader, div.navfooter { display: none; }
}
/*
CSS stylesheet for XHTML produced by DocBook XSL stylesheets.
Tested with XSL stylesheets 1.61.2, 1.67.2
*/
span.strong {
font-weight: bold;
}
body blockquote {
margin-top: .75em;
line-height: 1.5;
margin-bottom: .75em;
}
html body {
margin: 1em 5% 1em 5%;
line-height: 1.2;
}
body div {
margin: 0;
}