1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-16 14:04:52 +01:00
Commit graph

8622 commits

Author SHA1 Message Date
Johannes Schindelin
8bef62049b Fix spurious compile error
From time to time, I would get this error:

[...]
sed: -e expression #8, char 41: Unterminated `s' command
make: *** [git-add--interactive] Error 1

Turns out that the function WriteMakefile() called in Makefile.PL
outputs the message "Writing perl.mak for Git" to stdout! Thus,
the output of "make -C perl -s --no-print-directory instlibdir"
would be prefixed by that message whenever Makefile.PL was newer
than perl.mak.

This is fixed by redirecting stdout to stderr in Makefile.PL.

Signed-off-by: Johannes E. Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-16 13:43:50 -08:00
Shawn O. Pearce
2369ed7907 Print out the edge commits for each packfile in fast-import.
To help callers repack very large repositories into a series of
packfiles fast-import now outputs the last commits/tags it wrote to
a packfile when it prints out the packfile name.  This information
can be feed to pack-objects --revs to repack.  For the first pack
of an initial import this is pretty easy (just feed those SHA1s on
stdin) but for subsequent packs you want to feed the subsequent
pack's final SHA1s but also all prior pack's SHA1s prefixed with
the negation operator.  This way the prior pack's data does not
get included into the subsequent pack.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-16 16:18:44 -05:00
Junio C Hamano
a9877f83e0 git-rm documentation: remove broken behaviour from the example.
The example section were talking about the old broken default
behaviour.  Correct it.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-16 11:50:29 -08:00
Junio C Hamano
dc36f26525 git-push documentation: remaining bits
Mention --thin, --no-thin, --repo and -v.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-16 11:46:03 -08:00
Uwe Kleine-K,Av(Bnig
5214f77044 document --exec for git-push
The text is just copied from git-send-pack.txt.

Signed-off-by: Uwe Kleine-K,Av(Bnig <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-16 11:33:38 -08:00
Shawn O. Pearce
a7ddc48765 Correct object_count type and stat output in fast-import.
Since object_count is limited to 'unsigned long' (really an
unsigned 32 bit integer value) by the pack file format we may as
well use exactly that type here in fast-import for that counter.
An earlier change by me incorrectly made it uintmax_t.

But since object_count is a counter for the current packfile only,
we don't want to output its value at the end.  Instead we should
sum up the individual type counters and report that total, as that
will cover all of the packfiles.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-16 04:55:41 -05:00
Shawn O. Pearce
eec11c2484 Correct max_packsize default in fast-import.
Apparently amd64 has defined 'unsigned long' to be a 64 bit value,
which means -1 was way over the 4 GiB packfile limit.  Whoops.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-16 04:25:12 -05:00
Eric Wong
6f729591d1 git-svn: print and flush authentication prompts to STDERR
People that redirect STDOUT output should always see STDERR
prompts interactively.

STDERR should always be flushed without buffering, so
they should always show up.  If that is unset, we still
explicitly flush by calling STDERR->flush.

The svn command-line client prompts to STDERR, too.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-15 22:30:42 -08:00
Jason Riedy
d9e74d5745 Solaris 5.8 returns ENOTDIR for inappropriate renames.
The reflog code clears empty directories when rename returns
either EISDIR or ENOTDIR.  Seems to be the only place.

Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-15 22:27:05 -08:00
Jason Riedy
2aad957a51 Replace "echo -n" with printf in shell scripts.
Not all echos know -n.  This was causing a test failure in
t5401-update-hooks.sh, but not t3800-mktag.sh for some reason.

Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-15 22:23:21 -08:00
Jason Riedy
fb9522062c Set _ALL_SOURCE for AIX, but avoid its struct list.
AIX 5.3 seems to need _ALL_SOURCE for struct addrinfo, but that
introduces a struct list in grp.h.

Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-15 22:22:24 -08:00
Shawn O. Pearce
0fcbcae753 Remove unnecessary pack_fd global in fast-import.
Much like the pack_sha1 the pack_fd is an unnecessary global
variable, we already have the fd stored in our struct packed_git
*pack_data so that the core library functions in sha1_file.c are
able to lookup and decompress object data that we have previously
written.  Keeping an extra copy of this value in our own variable
is just a hold-over from earlier versions of fast-import and is
now completely unnecessary.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-16 01:20:57 -05:00
Shawn O. Pearce
1280158738 Ensure we close the packfile after creating it in fast-import.
Because we are renaming the packfile into its file destination we
need to be sure its not open when the rename is called, otherwise
some operating systems (e.g. Windows) may prevent the rename from
occurring.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-16 01:17:47 -05:00
Shawn O. Pearce
8455e48476 Use .keep files in fast-import during processing.
Because fast-import automatically updates all references (heads
and tags) at the end of its run the repository is corrupt unless
the objects are available in the .git/objects/pack directory prior
to the refs being modified.  The easiest way to ensure that is true
is to move the packfile and its associated index directly into the
.git/objects/pack directory as soon as we have finished output to it.

But the only safe way to do this is to create the a temporary .keep
file for that pack, so we use the same tricks that index-pack uses
when its being invoked by receive-pack.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-16 01:15:31 -05:00
Shawn O. Pearce
09543c96bb Reuse sha1 in packed_git in fast-import.
Rather than maintaing our own packfile level sha1 variable we
can make use of the one already available in struct packed_git.
Its meant for the SHA1 of the index but it can also hold the
SHA1 of the packfile itself between final checksumming of the
packfile and creation of the index.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-16 00:44:48 -05:00
Shawn O. Pearce
6cf0926193 Replace redundant yread() with read_in_full() in fast-import.
Prior to git having read_in_full() fast-import used its own private
function yread to perform the header reading task.  No sense in
keeping that around now that read_in_full is a public, stable
function.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-16 00:35:41 -05:00
Shawn O. Pearce
0ea9f045f4 Use uintmax_t for marks in fast-import.
If a frontend wants to use a mark per file revision and per commit
and is doing a truly huge import (such as a 32 GiB SVN repository)
we may need more than 2**32 unique mark values, especially if the
frontend is unable (or unwilling) to recycle mark values.  For mark
idnums we should use the largest unsigned integer type available,
hoping that will be at least 64 bits when we are compiled as a 64
bit executable.  This way we may consume huge amounts of memory
storing our mark table, but we'll at least be able to process
the entire import without failing.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-16 00:33:36 -05:00
Shawn O. Pearce
5d6f3ef641 Corrected buffer overflow during automatic checkpoint in fast-import.
If we previously were using a delta but we needed to checkpoint the
current packfile and switch to a new packfile we need to throw away
the delta and compress the raw object by itself, as delta chains
cannot span non-thin packfiles.  Unfortunately the output buffer
in this case needs to grow, as the size of the compressed object
may be quite a bit larger than the size of the compressed delta.

I've also avoided recompressing the object if we are checkpointing
and we didn't use a delta.  In this case the output buffer is the
correct size and has already been populated with the right data,
we just need to close out the current packfile and open a new one.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-15 23:40:27 -05:00
Jason Riedy
5ab9cc86ae Start all test scripts with /bin/sh.
My bash refused to run the two scripts missing a #!, and it's
better to use the same line for all the scripts.

Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-15 18:57:48 -08:00
Jeff King
a74b1706c8 git-pull: disallow implicit merging to detached HEAD
Instead, we complain to the user and suggest that they explicitly
specify the remote and branch. We depend on the exit status of
git-symbolic-ref, so let's go ahead and document that.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-15 15:37:22 -08:00
Junio C Hamano
a0f4280f9e Fix git-fetch while on detached HEAD not to give needlessly alarming errors
When we are on a detached HEAD, there is no current branch.
There is no reason to leak the error messages to the end user
since this is a situation we expect to see.

This adds -q option to git-symbolic-ref to exit without issuing
an error message if the given name is not a symbolic ref.

By the way, with or without this patch, there currently is no
good way to tell failure modes between "git symbolic-ref HAED"
and "git symbolic-ref HEAD".  Both says "is not a symbolic ref".

We may want to do something about it.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-15 15:35:07 -08:00
Junio C Hamano
15261e3b33 git reflog expire: document --stale-fix option.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-15 14:43:03 -08:00
Shawn O. Pearce
9d1b1b5ed7 Print the packfile names to stdout from fast-import.
Caller scripts may want to know what packfiles the fast-import
process just wrote out for them.  This is now output to stdout,
one packfile name per line, after we checkpoint each packfile.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-15 08:05:01 -05:00
Shawn O. Pearce
d9ee53ce45 Implemented automatic checkpoints within fast-import.
When the number of objects or number of bytes gets close to the limit
allowed by the packfile format (or configured on the command line by
our caller) we should automatically checkpoint the current packfile
and start a new one before writing the object out.  This does however
require that we abandon the delta (if we had one) as its not valid
in a new packfile.

I also added the simple rule that if we got a delta back but the
delta itself is the same size as or larger than the uncompressed
object to ignore the delta and just store the object data.  This
should avoid some really bad behavior caused by our current delta
strategy.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-15 08:00:49 -05:00
Shawn O. Pearce
2fce1f3c86 Optimize index creation on large object sets in fast-import.
When we are generating multiple packfiles at once we only need
to scan the blocks of object_entry structs which contain objects
for the current packfile.  Because the most recent blocks are at
the front of the linked list, and because all new objects going
into the current file are allocated from the front of that list,
we can stop scanning for objects as soon as we identify one which
doesn't belong to the current packfile.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-15 07:12:23 -05:00
Shawn O. Pearce
3e005baf85 Don't create a final empty packfile in fast-import.
If the last packfile is going to be empty (has 0 objects) then it
shouldn't be kept after the import has terminated, as there is no
point to the packfile.  So rather than hashing it and making the
index file, just delete the packfile.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-15 06:39:39 -05:00
Shawn O. Pearce
7bfe6e2613 Implemented manual packfile switching in fast-import.
To help importers which are dealing with massive amounts of data
fast-import needs to be able to close the packfile it is currently
writing to and open a new packfile for any additional data that
will be received.  A new 'checkpoint' command has been introduced
which can be used by the frontend import process to force this
to occur at any time.  This may be useful to ensure a very long
running import doesn't lose any work due to unexpected failures.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-15 06:35:41 -05:00
Shawn O. Pearce
80144727ac Remove unnecessary duplicate_count in fast-import.
There is little reason to be keeping a global duplicate_count
value when we also keep it per object type.  The global counter can
easily be computed at the end, once all processing has completed.
This saves us a couple of machine instructions in an unimportant
part of code.  But it looks slightly better to me to not keep
two counters around.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-15 06:05:22 -05:00
Shawn O. Pearce
f70b653429 Restructure fast-import to support creating multiple packfiles.
Now that we are starting to see some really large projects (such
as KDE or a fork of FreeBSD) get imported into Git we're running
into the upper limit on packfile object count as well as overall
byte length.  The KDE and FreeBSD projects are both likely to
require more than 4 GiB to store their current history, which means
we really need multiple packfiles to handle their content.

This is a fairly simple restructuring of the internal code to help
us support creating multiple packfiles from within fast-import.
We are now adding a 5 digit incrementing suffix to the end of the
basename supplied to us by the caller, permitting up to 99,999
packs to be generated in a single fast-import run.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-15 04:39:05 -05:00
Junio C Hamano
38ebbacd93 Merge git://git.kernel.org/pub/scm/gitk/gitk
* git://git.kernel.org/pub/scm/gitk/gitk:
  [PATCH] Make gitk work when launched in a subdirectory
  [PATCH] gitk: add current directory to main window title
2007-01-14 23:43:47 -08:00
Shawn O. Pearce
6e2931a8ed Use nice names in conflict markers during cherry-pick/revert.
Always call the current HEAD 'HEAD', and name the patch being
cherry-picked or reverted by its oneline subject rather than
its SHA1.  This matches git am's behavior and is done because
users most commonly are cherry-picking by SHA1 rather than by
ref name.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14 23:17:32 -08:00
Junio C Hamano
acb4441e0d Use merge-recursive in git-revert/git-cherry-pick
This makes revert and cherry-pick to use merge-recursive, to
allow them to notice renames.  A pair of test scripts
demonstrate that an old change before a rename happened can be
applied (reverted) after a rename with cherry-pick (with revert).

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14 22:00:34 -08:00
Junio C Hamano
5fe3acc43d Documentation: merge-output is not too verbose now.
We've squelched output from merge-recursive, and git-merge when
used with recursive does not attempt the trivial one first
anymore, so there won't be "Trying ... Nope." messages now.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14 21:31:30 -08:00
Shawn O. Pearce
e7eb50347b Remove hash in git-describe in favor of util slot.
Currently we don't use the util field of struct commit but we want
fast access to the highest priority name that references any given
commit object during our matching loop.  A really simple approach
is to just store the name directly in the util field.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14 21:17:27 -08:00
Shawn O. Pearce
cf69fd49ec Correct priority of lightweight tags in git-describe.
We really want to always favor an annotated tag over a lightweight
tag when describing a commit.  Unfortunately git-describe wasn't
doing this as it was favoring the depth attribute of a possible_tag
over the priority.  Now priority is the highest sort and we only
consider a lightweight tag if no annotated tags were identified.

Rather than searching for the minimum tag using a simple loop we
now sort them using a stable sort algorithm, this way the possible
tags display in order if --debug gets used.  The stable sort helps
to preseve the inherit topology/date order that we obtain during
our search loop.

This fix allows the tests in t6120-describe.sh to pass.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14 21:17:27 -08:00
Junio C Hamano
5312ab11fb Add describe test.
... with help from Shawn.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14 21:17:27 -08:00
Shawn O. Pearce
8713ab3079 Improve git-describe performance by reducing revision listing.
My prior version of git-describe ran very slowly on even reasonably
sized projects like git.git and linux.git as it tended to identify
a large number of possible tags and then needed to generate the
revision list for each of those tags to sort them and select the
best tag to describe the input commit.

All we really need is the number of commits in the input revision
which are not in the tag.  We can generate these counts during
the revision walking and tag matching loop by assigning a color to
each tag and coloring the commits as we walk them.  This limits us
to identifying no more than 26 possible tags, as there is limited
space available within the flags field of struct commit.

The limitation of 26 possible tags is hopefully not going to be a
problem in real usage, as most projects won't create 26 maintenance
releases and merge them back into a development trunk after the
development trunk was tagged with a release candidate tag.  If that
does occur git-describe will start to revert to its old behavior of
using the newer maintenance release tag to describe the development
trunk, rather than the development trunk's own tag.  The suggested
workaround would be to retag the development trunk's tip.

However since even 26 possible tags can take a while to generate a
description for on some projects I'm defaulting the limit to 10 but
offering the user --candidates to increase the number of possible
matches if they need a more accurate result.  I specifically chose
10 for the default as it seems unlikely projects will have more
than 10 maintenance releases merged into a development trunk before
retagging the development trunk, and it seems to perform about the
same on linux.git as v1.4.4.4 git-describe.

A large amount of debugging information was also added during
the development of this change, so I've left it in to be toggled
on with --debug.  It may be useful to the end user to help them
understand why git-describe took one particular tag over another.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14 21:17:27 -08:00
Shawn O. Pearce
910c0d7b5e Use binary searching on large buckets in git-describe.
If a project has a really huge number of tags (such as several
thousand tags) then we are likely to have nearly a hundred tags in
some buckets.  Scanning those buckets as linked lists could take
a large amount of time if done repeatedly during history traversal.

Since we are searching for a unique commit SHA1 we can sort all
tags by commit SHA1 and perform a binary search within the bucket.
Once we identify a particular tag as matching this commit we walk
backwards within the bucket matches to make sure we pick up the
highest priority tag for that commit, as the binary search may
have landed us in the middle of a set of tags which point at the
same commit.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14 21:17:27 -08:00
Shawn O. Pearce
c3e3cd4bf8 Hash tags by commit SHA1 in git-describe.
If a project has a very large number of tags then git-describe
will spend a good part of its time looping over the tags testing
them one at a time to determine if it matches a given commit.
For 10 tags this is not a big deal, but for hundreds of tags the
time could become considerable if we don't find an exact match for
the input commit and we need to walk back along the history chain.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14 21:17:27 -08:00
Shawn O. Pearce
dccd0c2abd Always perfer annotated tags in git-describe.
Several people have suggested that its always better to describe
a commit using an annotated tag, and to only use a lightweight tag
if absolutely no annotated tag matches the input commit.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14 21:17:27 -08:00
Shawn O. Pearce
03842d8e24 Misc. type cleanups within fast-import.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-15 00:16:23 -05:00
Nicolas Pitre
c14261eaa2 some doc updates
1) talk about "git merge" instead of "git pull ."

2) suggest "git repo-config" instead of directly editing config files

3) echo "URL: blah" > .git/remotes/foo is obsolete and should be
   "git repo-config remote.foo.url blah"

4) support for partial URL prefix has been removed (see commit
   ea560e6d64) so drop mention of it.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14 21:12:14 -08:00
J. Bruce Fields
2f99710cfe user-manual: rewrap, fix heading levels
Fix some heading levels that prevented compile; rewrap some stuff.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-01-14 22:43:47 -05:00
Shawn O. Pearce
d489bc1491 Improve reuse of sha1_file library within fast-import.
Now that the sha1_file.c library routines use the sliding mmap
routines to perform efficient access to portions of a packfile
I can remove that code from fast-import.c and just invoke it.
One benefit is we now have reloading support for any packfile which
uses OBJ_OFS_DELTA.  Another is we have significantly less code
to maintain.

This code reuse change *requires* that fast-import generate only
an OBJ_OFS_DELTA format packfile, as there is absolutely no index
available to perform OBJ_REF_DELTA lookup in while unpacking
an object.  This is probably reasonable to require as the delta
offsets result in smaller packfiles and are faster to unpack,
as no index searching is required.  Its also only a temporary
requirement as users could always repack without offsets before
making the import available to older versions of Git.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-14 22:33:51 -05:00
Junio C Hamano
adb7ba6b11 git log documentation: teach -<n> form.
We say "this shows only the most often used ones"; so instead of
teaching --max-number=<n> form, list -<n> form which is much
easier to type.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14 18:23:22 -08:00
J. Bruce Fields
67583917e9 Merge branch 'master' of git://git.kernel.org/pub/scm/git/git 2007-01-14 19:27:28 -05:00
J. Bruce Fields
69f7ad730a user-manual: reindent
Just some minor reindenting

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-01-14 16:29:40 -05:00
Shawn O. Pearce
89f40be294 Convert output messages in merge-recursive to past tense.
Now that we are showing the output messages for verbosity levels
<5 after all actions have been performed (due to the progress meter
running during the actions) it can be confusing to see messages in
the present tense when the user is looking at a '100% done' message
right above them.  Converting the messages to past tense will appear
more correct in this case, and shouldn't affect a developer who is
debugging the application and running it at a verbosity level >=5.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14 12:20:39 -08:00
Shawn O. Pearce
3f6ee2d15a Display a progress meter during merge-recursive.
Because large merges on slow systems can take up to a minute to
execute we should try to keep the user entertained with a progress
meter to let them know how far we have progressed through the
current merge.

The progress meter considers each entry in the in-memory index to
be a unit, which means a single recursive merge will double the
number of units in the progress meter.  Files which are unmerged
after the 3-way tree merge are also considered a unit within the
progress meter.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14 12:20:39 -08:00
Shawn O. Pearce
66a155bc12 Enable output buffering in merge-recursive.
Buffering all message output until a merge invocation is complete is
necessary to prevent intereferring with a progress meter that would
indicate the number of files completely merged, and how many remain.
This change does not introduce a progress meter, but merely lays
the groundwork to buffer the output.

To aid debugging output buffering is only enabled if verbosity
is lower than 5.  When using verbosity levels above 5 the user is
probably debugging the merge program itself and does not want to
see the output delayed, especially if they are stepping through
portions of the code in a debugger.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14 12:20:39 -08:00