summaryrefslogtreecommitdiff
path: root/server-info.c
AgeCommit message (Collapse)AuthorFilesLines
2019-05-28server-info: do not list unlinked packsLibravatar Eric Wong1-11/+7
Having non-existent packs in objects/info/packs causes dumb HTTP clients to abort. v2: use single loop with ALLOC_GROW as suggested by Jeff King Signed-off-by: Eric Wong <e@80x24.org> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-16update_info_refs(): drop unused force parameterLibravatar Jeff King1-2/+2
Once upon a time the force flag meant something when writing info/refs, but it hasn't done anything since 60d0526aaa (Unoptimize info/refs creation., 2005-09-14). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-16server-info: drop objdirlen pointer arithmeticLibravatar Jeff King1-8/+2
When writing objects/info/packs, we use the basename of each pack (i.e., just the "pack-1234abcd.pack" part). We compute that manually by adding "objdirlen + 6" to the name. This _should_ work consistently, as we do not include non-local packs, meaning everything should be in $objdir/pack/. Before f13d7db4af (server-info.c: use pack_local like everybody else., 2005-12-05), this was definitely true, since we computed "local" based on comparing the objdir string. Since then, we're relying on the code on packfile.c to match our expectations of p->pack_name and p->local. I think our expectations do still hold today, but we can be a bit more defensive by just using pack_basename() to get the base. That future-proofs us, and should hopefully be more obviously safe to somebody reading the code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-16server-info: drop nr_alloc struct memberLibravatar Jeff King1-1/+1
We keep an array of struct pointers, with each one representing a single packfile. But for some reason there is a nr_alloc parameter inside each struct, which has never been used. This is probably cruft left over from development, where we might have wanted a nr_alloc to dynamically grow the list. But as it turns out, we do not dynamically grow the list at all, but rather count up the total number of packs and use that as a maximum size. So while we're thinking of this, let's add an assert() that documents (and checks!) that our allocation and fill loops stay in sync. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-16server-info: use strbuf to read old info/packs fileLibravatar Jeff King1-10/+8
This old code uses fgets with a fixed-size buffer. Let's use a strbuf instead, so we don't have to wonder if "1000" is big enough, or what happens if we see a long line. This also lets us drop our custom code to trim the newline. Probably nobody actually cares about the 1000-char limit (after all, the lines generally only say "P pack-[0-9a-f]{40}.pack"), so this is mostly just about cleanup/readability. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-16server-info: simplify cleanup in parse_pack_def()Libravatar Jeff King1-3/+4
We have two exits from the function: either we jump to the out_stale label or not. But in both exits we repeat our cleanup, and the only difference is our return value. Let's just use a variable for the return value to avoid repeating ourselves. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-16server-info: fix blind pointer arithmeticLibravatar Jeff King1-10/+12
When we're writing out a new objects/info/packs file, we read back the old one to try to keep the ordering the same. When we see a line starting with "P", we expect "P pack-1234..." and blindly jump to "line + 2" to parse the pack name. If we saw a line with _just_ "P" and nothing else, we'd jump past the end of the buffer and start reading arbitrary memory. This shouldn't be a big attack vector, as the files are local to the repository and written by us, but it's clearly worth fixing (we do read remote copies of the file for dumb-http fetches, but using a totally different parser!). Let's instead use skip_prefix() here, which avoids pointer arithmetic altogether. Note that this converts our switch statement to an if/else chain, making it slightly more verbose. But it will also make it easier to do a few follow-on cleanups. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-20treewide: use get_all_packsLibravatar Derrick Stolee1-2/+2
There are many places in the codebase that want to iterate over all packfiles known to Git. The purposes are wide-ranging, and those that can take advantage of the multi-pack-index already do. So, use get_all_packs() instead of get_packed_git() to be sure we are iterating over all packfiles. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-29tag: add repository argument to deref_tagLibravatar Stefan Beller1-1/+1
Add a repository argument to allow the callers of deref_tag to be more specific about which repository to act on. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro to catch callers passing a repository other than the_repository at compile time. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-29object: add repository argument to parse_objectLibravatar Stefan Beller1-1/+1
Add a repository argument to allow the callers of parse_object to be more specific about which repository to act on. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro to catch callers passing a repository other than the_repository at compile time. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-02server-info: remove unused members from struct pack_infoLibravatar brian m. carlson1-7/+2
The head member of struct pack_info is completely unused and the nr_heads member is used only in one place, which is an assignment. This member was last usefully used in 3e15c67c90 (server-info: throw away T computation as well, 2005-12-04). Since this structure member is not useful, remove it. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-26packfile: keep prepare_packed_git() privateLibravatar Nguyễn Thái Ngọc Duy1-1/+0
The reason callers have to call this is to make sure either packed_git or packed_git_mru pointers are initialized since we don't do that by default. Sometimes it's hard to see this connection between where the function is called and where packed_git pointer is used (sometimes in separate functions). Keep this dependency internal because now all access to packed_git and packed_git_mru must go through get_xxx() wrappers. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-26packfile: add repository argument to prepare_packed_gitLibravatar Stefan Beller1-1/+1
Add a repository argument to allow prepare_packed_git callers to be more specific about which repository to handle. See commit "sha1_file: add repository argument to link_alt_odb_entry" for an explanation of the #define trick. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-26object-store: move packed_git and packed_git_mru to object storeLibravatar Stefan Beller1-2/+4
In a process with multiple repositories open, packfile accessors should be associated to a single repository and not shared globally. Move packed_git and packed_git_mru into the_repository and adjust callers to reflect this. [nd: while at there, wrap access to these two fields in get_packed_git() and get_packed_git_mru(). This allows us to lazily initialize these fields without caller doing that explicitly] Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-23pack: move {,re}prepare_packed_git and approximate_object_countLibravatar Jonathan Tan1-0/+1
Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-13Merge branch 'nd/fopen-errors'Libravatar Junio C Hamano1-1/+1
We often try to open a file for reading whose existence is optional, and silently ignore errors from open/fopen; report such errors if they are not due to missing files. * nd/fopen-errors: mingw_fopen: report ENOENT for invalid file names mingw: verify that paths are not mistaken for remote nicknames log: fix memory leak in open_next_file() rerere.c: move error_errno() closer to the source system call print errno when reporting a system call error wrapper.c: make warn_on_inaccessible() static wrapper.c: add and use fopen_or_warn() wrapper.c: add and use warn_on_fopen_errors() config.mak.uname: set FREAD_READS_DIRECTORIES for Darwin, too config.mak.uname: set FREAD_READS_DIRECTORIES for Linux and FreeBSD clone: use xfopen() instead of fopen() use xfopen() in more places git_fopen: fix a sparse 'not declared' warning
2017-05-26wrapper.c: add and use fopen_or_warn()Libravatar Nguyễn Thái Ngọc Duy1-1/+1
When fopen() returns NULL, it could be because the given path does not exist, but it could also be some other errors and the caller has to check. Add a wrapper so we don't have to repeat the same error check everywhere. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-08object: convert parse_object* to take struct object_idLibravatar brian m. carlson1-1/+1
Make parse_object, parse_object_or_die, and parse_object_buffer take a pointer to struct object_id. Remove the temporary variables inserted earlier, since they are no longer necessary. Transform all of the callers using the following semantic patch: @@ expression E1; @@ - parse_object(E1.hash) + parse_object(&E1) @@ expression E1; @@ - parse_object(E1->hash) + parse_object(E1) @@ expression E1, E2; @@ - parse_object_or_die(E1.hash, E2) + parse_object_or_die(&E1, E2) @@ expression E1, E2; @@ - parse_object_or_die(E1->hash, E2) + parse_object_or_die(E1, E2) @@ expression E1, E2, E3, E4, E5; @@ - parse_object_buffer(E1.hash, E2, E3, E4, E5) + parse_object_buffer(&E1, E2, E3, E4, E5) @@ expression E1, E2, E3, E4, E5; @@ - parse_object_buffer(E1->hash, E2, E3, E4, E5) + parse_object_buffer(E1, E2, E3, E4, E5) Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-17server-info: avoid calling fclose(3) twice in update_info_file()Libravatar René Scharfe1-3/+5
If an error occurs when or after closing the stream we call fclose(3) again in the error handler. The second call can exhibit undefined behavior, so make sure to call fclose(3) at most once. Also avoid calling close(2) after fd has been successfully associated with the stream, as fclose(3) has become responsible for doing that beyond this point. Found with Cppcheck. Signed-off-by: Rene Scharfe <l.s.r@web.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-29use QSORTLibravatar René Scharfe1-1/+1
Apply the semantic patch contrib/coccinelle/qsort.cocci to the code base, replacing calls of qsort(3) with QSORT. The resulting code is shorter and supports empty arrays with NULL pointers. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-09server-info.c: use error_errno()Libravatar Nguyễn Thái Ngọc Duy1-1/+1
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-20Convert struct object to object_idLibravatar brian m. carlson1-1/+1
struct object is one of the major data structures dealing with object IDs. Convert it to use struct object_id instead of an unsigned char array. Convert get_object_hash to refer to the new member as well. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Jeff King <peff@peff.net>
2015-05-25add_info_ref(): rewrite to take an object_id argumentLibravatar Michael Haggerty1-7/+5
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-25each_ref_fn: change to take an object_id parameterLibravatar Michael Haggerty1-1/+4
Change typedef each_ref_fn to take a "const struct object_id *oid" parameter instead of "const unsigned char *sha1". To aid this transition, implement an adapter that can be used to wrap old-style functions matching the old typedef, which is now called "each_ref_sha1_fn"), and make such functions callable via the new interface. This requires the old function and its cb_data to be wrapped in a "struct each_ref_fn_sha1_adapter", and that object to be used as the cb_data for an adapter function, each_ref_fn_adapter(). This is an enormous diff, but most of it consists of simple, mechanical changes to the sites that call any of the "for_each_ref" family of functions. Subsequent to this change, the call sites can be rewritten one by one to use the new interface. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-06update-server-info: create info/* with mode 0666Libravatar Jeff King1-1/+1
Prior to d38379e (make update-server-info more robust, 2014-09-13), we used a straight "fopen" to create the info/refs and objects/info/packs files, which creates the file using mode 0666 (less the default umask). In d38379e, we switched to creating the file with mkstemp to get a unique filename. But mkstemp also uses the more restrictive 0600 mode to create the file. This was an unintended side effect that we did not want, and causes problems when the repository is served by a different user than the one running update-server-info (it is not readable by a dumb http server running as `www`, for example). We can fix this by using git_mkstemp_mode and specifying 0666 to make sure that the umask is honored. Note that we could also say "just use core.sharedrepository", as we do call adjust_shared_perm on the result before renaming it into place. But that should not be necessary as long as everybody involved is using permissive umask to allow HTTP server to read necessary files. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-15server-info: clean up after writing info/packsLibravatar Jeff King1-0/+9
We allocate pack information in a static global list but never clean it up. This leaks memory, and means that calling update_server_info twice will generate a buggy file (it will have duplicate entries). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-15make update-server-info more robustLibravatar Jeff King1-45/+71
Since "git update-server-info" may be called automatically as part of a push or a "gc --auto", we should be robust against two processes trying to update it simultaneously. However, we currently use a fixed tempfile, which means that two simultaneous writers may step on each other's toes and end up renaming junk into place. Let's instead switch to using a unique tempfile via mkstemp. We do not want to use a lockfile here, because it's OK for two writers to simultaneously update (one will "win" the rename race, but that's OK; they should be writing the same information). While we're there, let's clean up a few other things: 1. Detect write errors. Report them and abort the update if any are found. 2. Free path memory rather than leaking it (and clean up the tempfile when necessary). 3. Use the pathdup functions consistently rather than static buffers or manually calculated lengths. This last one fixes a potential overflow of "infofile" in update_info_packs (e.g., by putting large junk into $GIT_OBJECT_DIRECTORY). However, this overflow was probably not an interesting attack vector for two reasons: a. The attacker would need to control the environment to do this, in which case it was already game-over. b. During its setup phase, git checks that the directory actually exists, which means it is probably shorter than PATH_MAX anyway. Because both update_info_refs and update_info_packs share these same failings (and largely duplicate each other), this patch factors out the improved error-checking version into a helper function. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-19update-server-info: Shorten read_pack_info_file()Libravatar Ralf Thielow1-3/+0
The correct responses to a D and a T line in .git/objects/info/packs are the same, so combine their case arms. In both cases we already ‘goto’ out of the switch so while at it, remove a redundant ‘break’ to avoid yet another line of code. Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com> Reviewed-by: Jonathan Nieder <jrnieder <at> gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-18Merge branch 'ar/unlink-err'Libravatar Junio C Hamano1-1/+1
* ar/unlink-err: print unlink(2) errno in copy_or_link_directory replace direct calls to unlink(2) with unlink_or_warn Introduce an unlink(2) wrapper which gives warning if unlink failed
2009-05-01Fix a bunch of pointer declarations (codestyle)Libravatar Felipe Contreras1-2/+2
Essentially; s/type* /type */ as per the coding guidelines. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-29replace direct calls to unlink(2) with unlink_or_warnLibravatar Alex Riesen1-1/+1
This helps to notice when something's going wrong, especially on systems which lock open files. I used the following criteria when selecting the code for replacement: - it was already printing a warning for the unlink failures - it is in a function which already printing something or is called from such a function - it is in a static function, returning void and the function is only called from a builtin main function (cmd_) - it is in a function which handles emergency exit (signal handlers) - it is in a function which is obvously cleaning up the lockfiles Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-30Use git_pathdup instead of xstrdup(git_path(...))Libravatar Alex Riesen1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-04Don't access line[-1] for a zero-length "line" from fgets.Libravatar Jim Meyering1-1/+1
A NUL byte at beginning of file, or just after a newline would provoke an invalid buf[-1] access in a few places. * builtin-grep.c (cmd_grep): Don't access buf[-1]. * builtin-pack-objects.c (get_object_list): Likewise. * builtin-rev-list.c (read_revisions_from_stdin): Likewise. * bundle.c (read_bundle_header): Likewise. * server-info.c (read_pack_info_file): Likewise. * transport.c (insert_packed_refs): Likewise. Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-25Print the real filename that we failed to open.Libravatar André Goddard Rosa1-1/+1
When we fail to open a temporary file to be renamed to something else, we reported the final filename, not the temporary file we failed to open. Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-11Fix core.sharedRepository = 2Libravatar Johannes Schindelin1-0/+2
For compatibility reasons, "git init --shared=all" does not write "all" into the config, but a number. In the shared setup, you really have to support even older clients on the _same_ repository. But git_config_perm() did not pick up on it. Also, "git update-server-info" failed to pick up on the shared permissions. This patch fixes both issues, and adds a test to prove it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Tested-by: martin f krafft <madduck@madduck.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-01-31Don't coredump on bad refs in update-server-info.Libravatar Shawn O. Pearce1-0/+2
Apparently if we are unable to parse an object update-server-info coredumps, as it doesn't bother to check the return value of its call to parse_object. Instead of coredumping, skip the ref. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-20Tell between packed, unpacked and symbolic refs.Libravatar Junio C Hamano1-1/+1
This adds a "int *flag" parameter to resolve_ref() and makes for_each_ref() family to call callback function with an extra "int flag" parameter. They are used to give two bits of information (REF_ISSYMREF and REF_ISPACKED) about the ref. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-20Add callback data to for_each_ref() family.Libravatar Junio C Hamano1-2/+2
This is a long overdue fix to the API for for_each_ref() family of functions. It allows the callers to specify a callback data pointer, so that the caller does not have to use static variables to communicate with the callback funciton. The updated for_each_ref() family takes a function of type int (*fn)(const char *, const unsigned char *, void *) and a void pointer as parameters, and calls the function with the name of the ref and its SHA-1 with the caller-supplied void pointer as parameters. The commit updates two callers, builtin-name-rev.c and builtin-pack-refs.c as an example. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-02Replace uses of strdup with xstrdup.Libravatar Shawn Pearce1-1/+1
Like xmalloc and xrealloc xstrdup dies with a useful message if the native strdup() implementation returns NULL rather than a valid pointer. I just tried to use xstrdup in new code and found it to be missing. However I expected it to be present as xmalloc and xrealloc are already commonly used throughout the code. [jc: removed the part that deals with last_XXX, which I am finding more and more dubious these days.] Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-12Remove TYPE_* constant macros and use object_type enums consistently.Libravatar Linus Torvalds1-1/+1
This updates the type-enumeration constants introduced to reduce the memory footprint of "struct object" to match the type bits already used in the packfile format, by removing the former (i.e. TYPE_* constant macros) and using the latter (i.e. enum object_type) throughout the code for consistency. Eventually we can stop passing around the "type strings" entirely, and this will help - no confusion about two different integer enumeration. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-09Assorted typo fixesLibravatar Pavel Roskin1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-17Shrink "struct object" a bitLibravatar Linus Torvalds1-1/+1
This shrinks "struct object" by a small amount, by getting rid of the "struct type *" pointer and replacing it with a 3-bit bitfield instead. In addition, we merge the bitfields and the "flags" field, which incidentally should also remove a useless 4-byte padding from the object when in 64-bit mode. Now, our "struct object" is still too damn large, but it's now less obviously bloated, and of the remaining fields, only the "util" (which is not used by most things) is clearly something that should be eventually discarded. This shrinks the "git-rev-list --all" memory use by about 2.5% on the kernel archive (and, perhaps more importantly, on the larger mozilla archive). That may not sound like much, but I suspect it's more on a 64-bit platform. There are other remaining inefficiencies (the parent lists, for example, probably have horrible malloc overhead), but this was pretty obvious. Most of the patch is just changing the comparison of the "type" pointer from one of the constant string pointers to the appropriate new TYPE_xxx small integer constant. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-21server-info: skip empty lines.Libravatar Junio C Hamano1-1/+4
Now we allow an empty line in objects/info/packs file, recognize that and stop complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-21objects/info/packs: work around bug in http-fetch.c::fetch_indices()Libravatar Junio C Hamano1-0/+1
The code to fetch pack index files in deployed clients have a bug that causes it to ignore the pack file on the last line of objects/info/packs file, so append an empty line to work it around. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-08qsort(): ptrdiff_t may be larger than intLibravatar Junio C Hamano1-1/+6
This is a companion patch to e23eff8be92a2a2cb66b53deef020063cff285ed commit. The same logic, the same rationale that a comparison function that returns an int should not just compute a ptrdiff_t and return it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-05server-info.c: and two functions are not used anymore.Libravatar Junio C Hamano1-33/+0
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-05server-info.c: use pack_local like everybody else.Libravatar Junio C Hamano1-4/+2
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-04server-info: throw away T computation as well.Libravatar Junio C Hamano1-130/+3
Again, dumb transport clients are too dumb to make use of the top objects information to make a choice among multiple packs, so computing these lines are useless for now. We could resurrect them if needed later. Also dumb transport clients presumably can do their own approximation by downloading idx files to see how relevant each pack is for their fetch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-04server-info: stop sorting packs by latest date.Libravatar Junio C Hamano1-36/+3
This does not seem to buy us much, for the same reason as the previous change. Dumb clients are still too dumb. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-04server-info.c: drop unused D lines.Libravatar Junio C Hamano1-110/+10
We tried to compute pack interdependency information in $GIT_DIR/objects/info/packs, hoping that dumb transports would make use of it when choosing from multiple choice, but that has never materialized, so stop computing D lines for now. Signed-off-by: Junio C Hamano <junkio@cox.net>