Signed-off-by: NJunio C Hamano <junkio@cox.net>

The offset of an object in the pack is recorded as a 4-byte integer
in the index file.  When reading the offset from the mmap'ed index
in prepare_pack_revindex(), the address is dereferenced as a long*.
This works fine as long as the long type is four bytes wide.  On
NetBSD/sparc64, however, a long is 8 bytes wide and so dereferencing
the offset produces garbage.

[jc: taking suggestion by Linus to use uint32_t]
Signed-off-by: NDennis Stosberg <dennis@stosberg.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Serge E. Hallyn noticed that we compute how many input bytes are
still left, but did not use it for sanity checking.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Let's avoid going south with invalid delta data.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This replaces occurences of "blob", "commit", "tag", and "tree",
where they're really used as type specifiers, which we already
have defined global constants for.
Signed-off-by: NPeter Eriksen <s022018@student.dtu.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Currently we unpack the delta data from the pack and then unpack
the base object to apply that delta data to it.  When getting an
object that is deeply deltified, we can reduce memory footprint
by unpacking the base object first and then unpacking the delta
data, because we will need to keep at most one delta data in
memory that way.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

When generating a new pack, notice if we have already needed
objects in existing packs.  If an object is stored deltified,
and its base object is also what we are going to pack, then
reuse the existing deltified representation unconditionally,
bypassing all the expensive find_deltas() and try_deltas()
calls.

Also, notice if what we are going to write out exactly match
what is already in an existing pack (either deltified or just
compressed).  In such a case, we can just copy it instead of
going through the usual uncompressing & recompressing cycle.

Without this patch, in linux-2.6 repository with about 1500
loose objects and a single mega pack:

    $ git-rev-list --objects v2.6.16-rc3 >RL
    $ wc -l RL
    184141 RL
    $ time git-pack-objects p <RL
    Generating pack...
    Done counting 184141 objects.
    Packing 184141 objects....................
    a1fc7b3e537fcb9b3c46b7505df859f0a11e79d2

    real    12m4.323s
    user    11m2.560s
    sys     0m55.950s

With this patch, the same input:

    $ time ../git.junio/git-pack-objects q <RL
    Generating pack...
    Done counting 184141 objects.
    Packing 184141 objects.....................
    a1fc7b3e537fcb9b3c46b7505df859f0a11e79d2
    Total 184141, written 184141, reused 182441

    real    1m2.608s
    user    0m55.090s
    sys     0m1.830s
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The real problem triggered an earlier fix was that an alternate
entry was pointing at a removed directory.  Complaining on
object/pack directory that cannot be opendir-ed produces noise
in an ancient repository that does not have object/pack
directory and has never been packed.

Detect the real user error and report it.  Also if opendir
failed for other reasons (e.g. no read permissions), report that
as well.

Spotted by Andrew Vasquez <andrew.vasquez@qlogic.com>.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NCarl Worth <cworth@cworth.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When generating a new pack, notice if we have already needed
objects in existing packs.  If an object is stored deltified,
and its base object is also what we are going to pack, then
reuse the existing deltified representation unconditionally,
bypassing all the expensive find_deltas() and try_deltas()
calls.

Also, notice if what we are going to write out exactly match
what is already in an existing pack (either deltified or just
compressed).  In such a case, we can just copy it instead of
going through the usual uncompressing & recompressing cycle.

Without this patch, in linux-2.6 repository with about 1500
loose objects and a single mega pack:

    $ git-rev-list --objects v2.6.16-rc3 >RL
    $ wc -l RL
    184141 RL
    $ time git-pack-objects p <RL
    Generating pack...
    Done counting 184141 objects.
    Packing 184141 objects....................
    a1fc7b3e537fcb9b3c46b7505df859f0a11e79d2

    real    12m4.323s
    user    11m2.560s
    sys     0m55.950s

With this patch, the same input:

    $ time ../git.junio/git-pack-objects q <RL
    Generating pack...
    Done counting 184141 objects.
    Packing 184141 objects.....................
    a1fc7b3e537fcb9b3c46b7505df859f0a11e79d2
    Total 184141, written 184141, reused 182441

    real    1m2.608s
    user    0m55.090s
    sys     0m1.830s
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The delta depth is unsigned.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Use stat() to explicitly check for existence rather than
relying on the non-portable EEXIST error in sha1_file.c's
safe_create_leading_directories().  There certainly are
optimizations possible, but then the code becomes almost
the same as that in coreutil's lib/mkdir-p.c.

Other uses of EEXIST seem ok.  Tested on Solaris 8, AIX 5.2L,
and a few Linux versions.  AIX has some unrelated (I think)
failures right now; I haven't tried many recent gits there.
Anyone have an old Ultrix box to break everything?  ;)

Also remove extraneous #includes.  Everything's already in
git-compat-util.h, included through cache.h.
Signed-off-by: NJason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This reverts c5ced645 commit.
It turns out that doing this check every time we map the idx file
is quite expensive.  A corrupt idx file is caught by git-fsck-objects,
so this check is not strictly necessary.

In one unscientific test, 0.99.9m spent 10 seconds usertime for
the same task 1.1.3 takes 37 seconds usertime.  Reverting this gives
us the performance of 0.99.9 back.

If the config variable 'core.sharedrepository' is set, the directories

	$GIT_DIR/objects/
	$GIT_DIR/objects/??
	$GIT_DIR/objects/pack
	$GIT_DIR/refs
	$GIT_DIR/refs/heads
	$GIT_DIR/refs/heads/tags

are set group writable (and g+s, since the git group may be not the primary
group of all users).

Since all files are written as lock files first, and then moved to
their destination, they do not have to be group writable.  Indeed, if
this leads to problems you found a bug.

Note that -- as in my first attempt -- the config variable is set in the
function which checks the repository format. If this were done in
git_default_config instead, a lot of programs would need to be modified
to call git_config(git_default_config) first.

[jc: git variables should be in environment.c unless there is a
 compelling reason to do otherwise.]
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Although pack-check.c had routine to verify the checksum for the
pack index file itself, the core did not check it before using
it.

This is stolen from the patch to tighten packname requirements.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
(cherry picked from 797bd6f4 commit)

Although pack-check.c had routine to verify the checksum for the
pack index file itself, the core did not check it before using
it.

This is stolen from the patch to tighten packname requirements.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

sha1_to_hex() returns a pointer to a static buffer. Some of its users
modify that buffer by appending a newline character. Other users rely
on the fact that you can call

	printf("%s", sha1_to_hex(sha1));

Just to be on the safe side, terminate the SHA1 in sha1_to_hex().
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

fprintf and die sometimes have missing/excessive "\n" in their arguments,
correct the strings where I think it would be appropriate.
Signed-off-by: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

add_packed_git() tries to get the pack SHA1 by parsing its name.  It may
access uninitialized memory for packs with short names.
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

In order to support getting data into git with scripts, this adds a
--stdin option to git-hash-object, which will make it read from stdin.
Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We somehow ended up registering packs in alternate object
directories as "dir/object//pack/pack-*", which confusd the
update-server-info code very badly.  Also we did not attempt to
detect a mistake of listing the object directory itself as one
of the alternates. This does not lead to incorrect behaviour,
but is simply wasteful, so try to do so when we are trivially
able to.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

An object name is 20-byte 'unsigned char', not 'char'.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This patch adds the program git-pack-intersect. It is
used to find redundant packs in git repositories.
Signed-off-by: NLukas Sandström <lukass@etek.chalmers.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This fixes a problem in safe_create_leading_directories() when the
argument starts with a '/' (i.e. the path is absolute).
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Recent FAT workaround caused compilation trouble on OpenBSD;
different platforms use different error codes when we try to
hardlink the temporary file to its final location.  Existing
Coda hack also checks its own error code, but the thing is,
the case we care about is if link failed for a reason other
than that the final file has already existed (which would be
normal, or it could mean collision).  So just check the error
code against EEXIST.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

FAT -- like Coda -- does not like cross-directory hard links. To be
precise, FAT does not like links at all. But links are not needed either.
So get rid of them.
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

If we want to re-pack just local packfiles, we need to know whether a
particular object is local or not.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This starts using the "user.name" and "user.email" config variables if
they exist as the default name and email when committing.  This means
that you don't have to use the GIT_COMMITTER_EMAIL environment variable
to override your email - you can just edit the config file instead.

The patch looks bigger than it is because it makes the default name and
email information non-static and renames it appropriately.  And it moves
the common git environment variables into a new library file, so that
you can link against libgit.a and get the git environment without having
to link in zlib and libcrypt.

In short, most of it is renaming and moving, the real change core is
just a few new lines in "git_default_config()" that copies the user
config values to the new base.

It also changes "git-var -l" to list the config variables.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The http commit walker cannot use the same temporary file
creation code because it needs to use predictable temporary
filename for partial fetch continuation purposes, but the code
to move the temporary file to the final location should be
usable from the ordinary object creation codepath.

Export move_temp_to_file from sha1_file.c and use it, while
losing the custom relink_or_rename function from http-fetch.c.

Also the temporary object file creation part needs to make sure
the leading path exists, in preparation of the really lazy
fan-out directory creation.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This makes it possible to have a "sparse" git object subdirectory
structure, something that has become much more attractive now that people
use pack-files all the time.

As a result of pack-files, a git object directory doesn't necessarily have
any individual objects lying around, and in that case it's just wasting
space to keep the empty first-level object directories around: on many
filesystems the 256 empty directories will be aboue 1MB of diskspace.

Even more importantly, after you re-pack a project that _used_ to be
unpacked, you could be left with huge directories that no longer contain
anything, but that waste space and take time to look through.

With this change, "git prune-packed" can just do an rmdir() on the
directories, and they'll get removed if empty, and re-created on demand.

This patch also tries to fix up "write_sha1_from_fd()" to use the new
common infrastructure for creating the object files, closing a hole where
we might otherwise leave half-written objects in the object database.

[jc: I unoptimized the part that really removes the fan-out directories
 to ease transition.  init-db still wastes 1MB of diskspace to hold 256
 empty fan-outs, and prune-packed rmdir()'s the grown but empty directories,
 but runs mkdir() immediately after that -- reducing the saving from 150KB
 to 146KB.  These parts will be re-introduced when everybody has the
 on-demand capability.]
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This adds more cruft to diff --git header to record the blob SHA1 and
the mode the patch/diff is intended to be applied against, to help the
receiving end fall back on a three-way merge.  The new header looks
like this:

    diff --git a/apply.c b/apply.c
    index 7be5041..8366082 100644
    --- a/apply.c
    +++ b/apply.c
    @@ -14,6 +14,7 @@
     //    files that are being modified, but doesn't apply the patch
     //  --stat does just a diffstat, and doesn't actually apply
    +//  --show-index-info shows the old and new index info for...
    ...

Upon receiving such a patch, if the patch did not apply cleanly to the
target tree, the recipient can try to find the matching old objects in
her object database and create a temporary tree, apply the patch to
that temporary tree, and attempt a 3-way merge between the patched
temporary tree and the target tree using the original temporary tree
as the common ancestor.

The patch lifts the code to compute the hash for an on-filesystem
object from update-index.c and makes it available to the diff output
routine.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junio@twinsun.com>

The core part detected and died upon seeing a corrupted packfile, but
did not help the user by telling which packfile is corrupt and how.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NSven Verdoolaege <skimo@kotnet.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

An entry in the alternates file can name a directory relative to
the object store it describes.  A typical linux-2.6 maintainer
repository would have "../../../torvalds/linux-2.6.git/objects" there,
because the subsystem maintainer object store would live in

    /pub/scm/linux/kernel/git/$u/$system.git/objects/

and the object store of Linus tree is in

    /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/

This unfortunately is different from GIT_ALTERNATE_OBJECT_DIRECTORIES
which is relative to the cwd of the running process, but there is no
way to make it consistent with the behaviour of the environment
variable.  The process typically is run in $system.git/ directory for
a naked repository, or one level up for a repository with a working
tree, so we just define it to be relative to the objects/ directory
to be different from either ;-).

Later, the dumb transport could be updated to read from info/alternates
and make requests for the repository the repository borrows from.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We have deprecated the old environment variable names for quite a
while and now it's time to remove them.  Gone are:

    SHA1_FILE_DIRECTORIES AUTHOR_DATE AUTHOR_EMAIL AUTHOR_NAME
    COMMIT_AUTHOR_EMAIL COMMIT_AUTHOR_NAME SHA1_FILE_DIRECTORY
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Hi. This patch contains the following possible cleanups:

 * Make some needlessly global functions in local-pull.c static
 * Change 'char *' to 'const char *' where appropriate
Signed-off-by: NPeter Hagervall <hager@cs.umu.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Omitting the first branch in ?: is a GNU extension.  Cute,
but not supported by other compilers.  Replaced mostly
by explicit tests.  Calls to getenv() simply are repeated
on non-GNU compilers.
Signed-off-by: NJason Riedy <ejr@cs.berkeley.edu>