git/cache.h, branch v1.2.2

Make "git clone" less of a deathly quiet experience

2006-02-11T06:28:30Z

It used to be that "git-unpack-objects" would give nice percentages, but now that we don't unpack the initial clone pack any more, it doesn't. And I'd love to do that nice percentage view in the pack objects downloader too, but the thing doesn't even read the pack header, much less know how much it's going to get, so I was lazy and didn't. Instead, it at least prints out how much data it's gotten, and what the packing speed is. Which makes the user realize that it's actually doing something useful instead of sitting there silently (and if the recipient knows how large the final result is, he can at least make a guess about when it migt be done). So with this patch, I get something like this on my DSL line: [torvalds@g5 ~]$ time git clone master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6 clone-test Packing 188543 objects 48.398MB (154 kB/s) where even the speed approximation seems to be roughtly correct (even though my algorithm is a truly stupid one, and only really gives "speed in the last half second or so"). Anyway, _something_ like this is definitely needed. It could certainly be better (if it showed the same kind of thing that git-unpack-objects did, that would be much nicer, but would require parsing the object stream as it comes in). But this is big step forward, I think. Signed-off-by: Linus Torvalds Signed-off-by: Junio C Hamano

abbrev cleanup: use symbolic constants

2006-01-28T08:09:38Z

The minimum length of abbreviated object name was hardcoded in different places to be 4, risking inconsistencies in the future. Also there were three different "default abbreviation precision". Use two C preprocessor symbols to clean up this mess. Signed-off-by: Junio C Hamano

Only use a single parser for tree objects

2006-01-26T09:08:29Z

This makes read_tree_recursive and read_tree take a struct tree instead of a buffer. It also move the declaration of read_tree into tree.h (where struct tree is defined), and updates ls-tree and diff-index (the only places that presently use read_tree*()) to use the new versions. Signed-off-by: Daniel Barkalow Signed-off-by: Junio C Hamano

Undef DT_* before redefining them.

2006-01-22T03:33:22Z

When overriding DT_* macro detection with NO_D_TYPE_IN_DIRENT (recent Cygwin build problem, which hopefully is already fixed in their CVS snapshot version), we define DTYPE() macro to return just "we do not know", but still needed to use DT_* macro to avoid ifdef in the code we use them. If the platform defines DT_* macro but with unusable d_type, this would have resulted in us redefining these preprocessor symbols. Admittedly, that would be just a couple of compilation warnings, and on Cygwin at least this particular problem is transitory (the problem is already fixed in their CVS snapshot version), so this is a low priority fix. Signed-off-by: Junio C Hamano

DT_UNKNOWN: do not fully trust existence of DT_UNKNOWN

2006-01-22T03:33:22Z

The recent Cygwin defines DT_UNKNOWN although it does not have d_type in struct dirent. Give an option to tell us not to use d_type on such platforms. Hopefully this problem will be transient. Signed-off-by: Junio C Hamano

GIT 1.1.0

2006-01-08T22:22:19Z

[PATCH] Compilation: zero-length array declaration.

2006-01-07T18:51:06Z

ISO C99 (and GCC 3.x or later) lets you write a flexible array at the end of a structure, like this: struct frotz { int xyzzy; char nitfol[]; /* more */ }; GCC 2.95 and 2.96 let you to do this with "char nitfol[0]"; unfortunately this is not allowed by ISO C90. This declares such construct like this: struct frotz { int xyzzy; char nitfol[FLEX_ARRAY]; /* more */ }; and git-compat-util.h defines FLEX_ARRAY to 0 for gcc 2.95 and empty for others. If you are using a C90 C compiler, you should be able to override this with CFLAGS=-DFLEX_ARRAY=1 from the command line of "make". Signed-off-by: Junio C Hamano

Introduce core.sharedrepository

2005-12-24T08:21:10Z

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: Johannes Schindelin Signed-off-by: Junio C Hamano

fetch-pack: -k option to keep downloaded pack.

2005-12-18T07:11:29Z

Split out the functions that deal with the socketpair after finishing git protocol handshake to receive the packed data into a separate file, and use it in fetch-pack to keep/explode the received pack data. We earlier had something like that on clone-pack side once, but the list discussion resulted in the decision that it makes sense to always keep the pack for clone-pack, so unpacking option is not enabled on the clone-pack side, but we later still could do so easily if we wanted to with this change. Signed-off-by: Junio C Hamano

Allow saving an object from a pipe

2005-12-11T02:57:57Z

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: Daniel Barkalow Signed-off-by: Junio C Hamano