summaryrefslogtreecommitdiff
path: root/server-info.c
AgeCommit message (Collapse)AuthorFilesLines
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>
2005-11-15Rework object refs tracking to reduce memory usageLibravatar Sergey Vlasov1-7/+18
Store pointers to referenced objects in a variable sized array instead of linked list. This cuts down memory usage of utilities which use object references; e.g., git-fsck-objects --full on the git.git repository consumes about 2 MB of memory tracked by Massif instead of 7 MB before the change. Object refs are still the biggest consumer of memory (57%), but the malloc overhead for a single block instead of a linked list is substantially smaller. Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-02Be careful when dereferencing tags.Libravatar Junio C Hamano1-3/+4
One caller of deref_tag() was not careful enough to make sure what deref_tag() returned was not NULL (i.e. we found a tag object that points at an object we do not have). Fix it, and warn about refs that point at such an incomplete tag where needed. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-15Show peeled onion from upload-pack and server-info.Libravatar Junio C Hamano1-0/+7
This updates git-ls-remote to show SHA1 names of objects that are referred by tags, in the "ref^{}" notation. This would make git-findtags (without -t flag) almost trivial. git-peek-remote . | sed -ne "s:^$target "'refs/tags/\(.*\)^{}$:\1:p' Also Pasky could do: git-ls-remote --tags $remote | sed -ne 's:\( refs/tags/.*\)^{}$:\1:p' to find out what object each of the remote tags refers to, and if he has one locally, run "git-fetch $remote tag $tagname" to automatically catch up with the upstream tags. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-08Reduce memory usage in git-update-server-info.Libravatar robfitz@273k.net1-0/+10
Modify parse_object_cheap() to also free all the entries from the tree data structures. Signed-off-by: Robert Fitzsimons <robfitz@273k.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-15Unoptimize info/refs creation.Libravatar Junio C Hamano1-26/+0
The code did not catch the case where you removed an existing ref without changing anything else. We are not talking about hundreds of refs anyway, so remove that optimization. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-15Retire info/rev-cacheLibravatar Junio C Hamano1-41/+0
It was one of those things that were well intentioned but did not turn out to be useful in practice. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-29Revert "Replace zero-length array decls with []."Libravatar Junio C Hamano1-1/+1
This reverts 6c5f9baa3bc0d63e141e0afc23110205379905a4 commit, whose change breaks gcc-2.95. Not that I ignore portability to compilers that are properly C99, but keeping compilation with GCC working is more important, at least for now. We would probably end up declaring with "name[1]" and teach the allocator to subtract one if we really aimed for portability, but that is left for later rounds. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-23Replace zero-length array decls with [].Libravatar Jason Riedy1-1/+1
C99 denotes variable-sized members with [], not [0]. Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
2005-08-01[PATCH] Fix sparse warningsLibravatar Linus Torvalds1-1/+1
A few sparse warnings have crept in again since I checked last time: undeclared variables with global scope. Fix them by marking the private variables properly "static". Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-29server-info: do not complain if a tag points at a non-commit.Libravatar Junio C Hamano1-4/+11
Linux 2.6 tree has one of those tree tags. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-23[PATCH] Add update-server-info.Libravatar Junio C Hamano1-0/+565
The git-update-server-info command prepares informational files to help clients discover the contents of a repository, and pull from it via a dumb transport protocols. Currently, the following files are produced. - The $repo/info/refs file lists the name of heads and tags available in the $repo/refs/ directory, along with their SHA1. This can be used by git-ls-remote command running on the client side. - The $repo/info/rev-cache file describes the commit ancestry reachable from references in the $repo/refs/ directory. This file is in an append-only binary format to make the server side friendly to rsync mirroring scheme, and can be read by git-show-rev-cache command. - The $repo/objects/info/pack file lists the name of the packs available, the interdependencies among them, and the head commits and tags contained in them. Along with the other two files, this is designed to help clients to make smart pull decisions. The git-receive-pack command is changed to invoke it at the end, so just after a push to a public repository finishes via "git push", the server info is automatically updated. In addition, building of the rev-cache file can be done by a standalone git-build-rev-cache command separately. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>