Nicolas Pitre 748af44c63 sha1_file: be paranoid when creating loose objects
We don't want the data being deflated and stored into loose objects
to be different from what we expect.  While the deflated data is
protected by a CRC which is good enough for safe data retrieval
operations, we still want to be doubly sure that the source data used
at object creation time is still what we expected once that data has
been deflated and its CRC32 computed.

The most plausible data corruption may occur if the source file is
modified while Git is deflating and writing it out in a loose object.
Or Git itself could have a bug causing memory corruption.  Or even bad
RAM could cause trouble.  So it is best to make sure everything is
coherent and checksum protected from beginning to end.

To do so we compute the SHA1 of the data being deflated _after_ the
deflate operation has consumed that data, and make sure it matches
with the expected SHA1.  This way we can rely on the CRC32 checked by
the inflate operation to provide a good indication that the data is still
coherent with its SHA1 hash.  One pathological case we ignore is when
the data is modified before (or during) deflate call, but changed back
before it is hashed.

There is some overhead of course. Using 'git add' on a set of large files:

Before:

	real    0m25.210s
	user    0m23.783s
	sys     0m1.408s

After:

	real    0m26.537s
	user    0m25.175s
	sys     0m1.358s

The overhead is around 5% for full data coherency guarantee.

Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-21 22:33:25 -08:00
2010-02-12 15:45:05 -08:00
2010-02-07 15:52:28 -08:00
2010-02-10 13:46:15 -08:00
2010-01-25 09:42:31 -08:00
2009-09-14 02:23:36 -07:00
2010-01-20 14:42:59 -08:00
2010-01-20 14:42:59 -08:00
2008-07-19 11:17:43 -07:00
2010-01-16 20:39:59 -08:00
2010-01-16 20:39:59 -08:00
2010-01-20 14:37:25 -08:00
2010-02-07 15:52:12 -08:00
2010-01-22 16:08:19 -08:00
2008-08-28 20:50:10 -07:00
2009-12-26 14:03:16 -08:00
2009-12-03 10:08:54 -08:00
2010-02-05 09:27:25 -08:00
2009-08-05 12:39:33 -07:00
2010-01-22 10:01:33 -08:00
2010-01-29 09:56:12 -08:00
2010-01-13 11:58:56 -08:00
2010-01-22 16:08:16 -08:00
2010-01-21 22:04:42 -08:00
2009-08-07 22:35:17 -07:00
2010-01-22 10:10:27 -08:00
2009-11-23 22:30:08 -08:00
2009-02-13 17:27:58 -08:00
2010-01-29 23:36:13 -08:00
2010-01-20 14:39:52 -08:00
2009-09-13 01:32:26 -07:00
2008-10-10 08:39:20 -07:00
2009-05-01 16:07:29 -07:00
2010-01-27 14:56:42 -08:00
2009-05-20 00:02:24 -07:00
2009-06-18 09:22:46 -07:00
2010-01-26 22:53:13 -08:00
2010-01-24 17:35:58 -08:00
2010-01-13 11:58:34 -08:00
2010-01-20 14:37:25 -08:00
2010-01-13 11:58:34 -08:00
2009-12-08 22:47:09 -08:00
2010-02-11 22:10:00 -08:00
2010-02-11 23:06:32 -08:00
2009-12-13 23:40:24 -08:00
2008-07-13 14:12:48 -07:00
2010-02-04 23:33:25 -08:00
2010-02-12 15:45:05 -08:00
2010-02-05 09:27:25 -08:00
2010-02-03 12:03:40 -08:00
2010-01-26 09:20:07 -08:00
2008-09-07 23:52:16 -07:00
2010-01-21 20:03:45 -08:00
2010-02-08 21:54:10 -08:00
2009-04-22 19:02:12 -07:00
2010-01-12 01:06:09 -08:00
2010-01-12 01:06:09 -08:00
2010-01-21 20:08:31 -08:00
2010-01-17 22:49:36 -08:00
2010-01-17 22:49:36 -08:00
2010-01-22 10:10:27 -08:00
2010-01-22 10:10:27 -08:00
2010-02-10 13:44:11 -08:00
2010-01-21 20:08:31 -08:00
2010-01-09 23:34:10 -08:00
2010-01-09 23:34:10 -08:00
2010-01-28 09:30:14 -08:00
2010-01-20 14:46:35 -08:00
2010-01-26 13:49:50 -08:00
2009-11-04 17:58:15 -08:00
2008-07-21 19:11:50 -07:00
2010-01-21 20:03:45 -08:00
2009-11-04 17:58:15 -08:00
2010-01-20 20:28:50 -08:00
2010-01-31 10:25:23 -08:00
2010-01-17 22:49:36 -08:00
2008-03-02 15:11:07 -08:00
2009-01-17 18:30:41 -08:00
2009-08-30 22:04:46 -07:00
2009-08-23 17:11:28 -07:00
2009-04-20 13:44:14 -07:00
2010-01-24 17:35:58 -08:00
2010-01-24 17:35:58 -08:00
2009-12-10 16:20:59 -08:00
2009-11-22 16:14:48 -08:00
2010-01-16 20:39:59 -08:00
2010-01-12 01:06:09 -08:00
2010-01-12 01:06:09 -08:00
2009-07-22 21:57:41 -07:00
2010-01-26 12:57:53 -08:00
2010-01-16 20:39:59 -08:00
2010-01-22 16:08:10 -08:00

////////////////////////////////////////////////////////////////

	GIT - the stupid content tracker

////////////////////////////////////////////////////////////////

"git" can mean anything, depending on your mood.

 - random three-letter combination that is pronounceable, and not
   actually used by any common UNIX command.  The fact that it is a
   mispronunciation of "get" may or may not be relevant.
 - stupid. contemptible and despicable. simple. Take your pick from the
   dictionary of slang.
 - "global information tracker": you're in a good mood, and it actually
   works for you. Angels sing, and a light suddenly fills the room.
 - "goddamn idiotic truckload of sh*t": when it breaks

Git is a fast, scalable, distributed revision control system with an
unusually rich command set that provides both high-level operations
and full access to internals.

Git is an Open Source project covered by the GNU General Public License.
It was originally written by Linus Torvalds with help of a group of
hackers around the net. It is currently maintained by Junio C Hamano.

Please read the file INSTALL for installation instructions.

See Documentation/gittutorial.txt to get started, then see
Documentation/everyday.txt for a useful minimum set of commands, and
Documentation/git-commandname.txt for documentation of each command.
If git has been correctly installed, then the tutorial can also be
read with "man gittutorial" or "git help tutorial", and the
documentation of each command with "man git-commandname" or "git help
commandname".

CVS users may also want to read Documentation/gitcvs-migration.txt
("man gitcvs-migration" or "git help cvs-migration" if git is
installed).

Many Git online resources are accessible from http://git-scm.com/
including full documentation and Git related tools.

The user discussion and development of Git take place on the Git
mailing list -- everyone is welcome to post bug reports, feature
requests, comments and patches to git@vger.kernel.org. To subscribe
to the list, send an email with just "subscribe git" in the body to
majordomo@vger.kernel.org. The mailing list archives are available at
http://marc.theaimsgroup.com/?l=git and other archival sites.

The messages titled "A note from the maintainer", "What's in
git.git (stable)" and "What's cooking in git.git (topics)" and
the discussion following them on the mailing list give a good
reference for project status, development direction and
remaining tasks.
Description
No description provided
Readme 279 MiB
Languages
C 50.5%
Shell 38.7%
Perl 4.5%
Tcl 3.2%
Python 0.8%
Other 2.1%