summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2010-03-04Merge branch 'jn/maint-fix-pager' into maintLibravatar Junio C Hamano10-15/+268
* jn/maint-fix-pager: tests: Fix race condition in t7006-pager t7006-pager: if stdout is not a terminal, make a new one tests: Add tests for automatic use of pager am: Fix launching of pager git svn: Fix launching of pager git.1: Clarify the behavior of the --paginate option Make 'git var GIT_PAGER' always print the configured pager Fix 'git var' usage synopsis
2010-03-04Merge branch 'tr/maint-cherry-pick-list' into maintLibravatar Junio C Hamano1-0/+3
* tr/maint-cherry-pick-list: cherry_pick_list: quit early if one side is empty
2010-03-04Merge branch 'ld/maint-diff-quiet-w' into maintLibravatar Junio C Hamano2-0/+38
* ld/maint-diff-quiet-w: git-diff: add a test for git diff --quiet -w git diff --quiet -w: check and report the status
2010-03-04Merge branch 'rs/optim-text-wrap' into maintLibravatar Junio C Hamano3-37/+42
* rs/optim-text-wrap: utf8.c: speculatively assume utf-8 in strbuf_add_wrapped_text() utf8.c: remove strbuf_write() utf8.c: remove print_spaces() utf8.c: remove print_wrapped_text()
2010-03-04Merge branch 'dp/read-not-mmap-small-loose-object' into maintLibravatar Junio C Hamano1-0/+10
* dp/read-not-mmap-small-loose-object: hash-object: don't use mmap() for small files
2010-03-04Merge branch 'np/compress-loose-object-memsave' into maintLibravatar Junio C Hamano1-14/+19
* np/compress-loose-object-memsave: sha1_file: be paranoid when creating loose objects sha1_file: don't malloc the whole compressed result when writing out objects
2010-03-04Merge branch 'jc/maint-status-preload' into maintLibravatar Junio C Hamano1-1/+1
* jc/maint-status-preload: status: preload index to optimize lstat(2) calls
2010-03-04Merge branch 'gf/maint-sh-setup-nongit-ok' into maintLibravatar Junio C Hamano1-1/+1
* gf/maint-sh-setup-nongit-ok: require_work_tree broken with NONGIT_OK
2010-03-04Merge branch 'cc/maint-bisect-paths' into maintLibravatar Junio C Hamano2-0/+11
* cc/maint-bisect-paths: bisect: error out when passing bad path parameters
2010-03-04Merge branch 'maint-1.6.6' into maintLibravatar Junio C Hamano1-1/+1
* maint-1.6.6: Remove extra '-' from git-am(1)
2010-03-04Merge branch 'maint-1.6.5' into maint-1.6.6Libravatar Junio C Hamano1-1/+1
* maint-1.6.5: Remove extra '-' from git-am(1)
2010-03-04Remove extra '-' from git-am(1)Libravatar Michal Sojka1-1/+1
Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-02Start preparing for 1.7.0.2Libravatar Junio C Hamano2-1/+23
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-02Merge branch 'tc/maint-transport-ls-remote-with-void' into maintLibravatar Junio C Hamano2-1/+10
* tc/maint-transport-ls-remote-with-void: transport: add got_remote_refs flag
2010-03-02Merge branch 'hm/maint-imap-send-crlf' into maintLibravatar Junio C Hamano1-1/+39
* hm/maint-imap-send-crlf: git-imap-send: Convert LF to CRLF before storing patch to draft box
2010-03-02Merge branch 'sp/maint-push-sideband' into maintLibravatar Junio C Hamano10-134/+370
* sp/maint-push-sideband: receive-pack: Send internal errors over side-band #2 t5401: Use a bare repository for the remote peer receive-pack: Send hook output over side band #2 receive-pack: Wrap status reports inside side-band-64k receive-pack: Refactor how capabilities are shown to the client send-pack: demultiplex a sideband stream with status data run-command: support custom fd-set in async run-command: Allow stderr to be a caller supplied pipe Conflicts: builtin-receive-pack.c run-command.c t/t5401-update-hooks.sh
2010-03-02Merge branch 'jc/maint-fix-test-perm' into maintLibravatar Junio C Hamano2-0/+4
* jc/maint-fix-test-perm: lib-patch-mode.sh: Fix permission t6000lib: Fix permission
2010-03-02Merge branch 'np/fast-import-idx-v2' into maintLibravatar Junio C Hamano2-95/+84
* np/fast-import-idx-v2: fast-import: use the diff_delta() max_delta_size argument fast-import: honor pack.indexversion and pack.packsizelimit config vars fast-import: make default pack size unlimited fast-import: use write_idx_file() instead of custom code fast-import: use sha1write() for pack data fast-import: start using struct pack_idx_entry
2010-03-02gitweb: Fix project-specific feature override behaviorLibravatar Jakub Narebski2-6/+21
This commit fixes a bug in processing project-specific override in a situation when there is no project, e.g. for the projects list page. When 'snapshot' feature had project specific config override enabled by putting $feature{'snapshot'}{'override'} = 1; (or equivalent) in $GITWEB_CONFIG, and when viewing toplevel gitweb page, which means the projects list page (to be more exact this happens for any project-less action), gitweb would put the following Perl warnings in error log: gitweb.cgi: Use of uninitialized value $git_dir in concatenation (.) or string at gitweb.cgi line 2065. fatal: error processing config file(s) gitweb.cgi: Use of uninitialized value $git_dir in concatenation (.) or string at gitweb.cgi line 2221. gitweb.cgi: Use of uninitialized value $git_dir in concatenation (.) or string at gitweb.cgi line 2218. The problem is in the following fragment of code: # path to the current git repository our $git_dir; $git_dir = "$projectroot/$project" if $project; # list of supported snapshot formats our @snapshot_fmts = gitweb_get_feature('snapshot'); @snapshot_fmts = filter_snapshot_fmts(@snapshot_fmts); For the toplevel gitweb page, which is the list of projects, $project is not defined, therefore neither is $git_dir. gitweb_get_feature() subroutine calls git_get_project_config() if project specific override is turned on... but we don't have project here. Those errors mentioned above occur in the following fragment of code in git_get_project_config(): # get config if (!defined $config_file || $config_file ne "$git_dir/config") { %config = git_parse_project_config('gitweb'); $config_file = "$git_dir/config"; } git_parse_project_config() calls git_cmd() which has '--git-dir='.$git_dir There are (at least) three possible solutions: 1. Harden gitweb_get_feature() so that it doesn't call git_get_project_config() if $project (and therefore $git_dir) is not defined; there is no project for project specific config. 2. Harden git_get_project_config() like you did in your fix, returning early if $git_dir is not defined. 3. Harden git_cmd() so that it doesn't add "--git-dir=$git_dir" if $git_dir is not defined, and change git_get_project_config() so that it doesn't even try to access $git_dir if it is not defined. This commit implements both 1.) and 2.), i.e. gitweb_get_feature() doesn't call project-specific override if $git_dir is not defined (if there is no project), and git_get_project_config() returns early if $git_dir is not defined. Add a test for this bug to t/t9500-gitweb-standalone-no-errors.sh test. Reported-by: Eli Barzilay <eli@barzilay.org> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-02gitweb multiple project roots documentationLibravatar Sylvain Rabot1-3/+64
This commit adds in the gitweb/README file a description of how to use gitweb with several project roots using apache virtualhost rewrite rules. Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr> Acked-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-01bisect: error out when passing bad path parametersLibravatar Christian Couder2-0/+11
As reported by Mark Lodato, "git bisect", when it was started with path parameters that match no commit was kind of working without taking account of path parameters and was reporting something like: Bisecting: -1 revisions left to test after this (roughly 0 steps) It is more correct and safer to just error out in this case, before displaying the revisions left, so this patch does just that. Note that this bug is very old, it exists at least since v1.5.5. And it is possible to detect that case earlier in the bisect algorithm, but it is not clear that it would be an improvement to error out earlier, on the contrary it may change the behavior of "git rev-list --bisect-all" for example, which is currently correct. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-28Git 1.7.0.1Libravatar Junio C Hamano3-7/+12
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-28Remove reference to GREP_COLORS from documentationLibravatar Mark Lodato1-3/+1
There is no longer support for external grep, as per bbc09c2 (grep: rip out support for external grep, 2010-01-12), so remove the reference to it from the documentation. Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-28sha1_name: fix segfault caused by invalid index accessLibravatar Markus Heidelberg1-14/+18
The code to see if user input "git show :path" makes sense tried to access the index without properly checking the array bound. Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-25Merge branch 'maint-1.6.6' into maintLibravatar Junio C Hamano1-0/+1
* maint-1.6.6: t3301-notes: insert a shbang line in ./fake_editor.sh
2010-02-25t3301-notes: insert a shbang line in ./fake_editor.shLibravatar Johannes Sixt1-0/+1
This is required on Windows because git-notes is now a built-in rather than a shell script. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-24commit: quote the user name in the exampleLibravatar Matt Kraai1-1/+1
If the user runs git config --global user.name Your Name as suggested, user.name will be set to "Your". With this patch, the suggested command will be git config --global user.name "Your Name" which will set user.name to "Your Name" and hopefully help users avoid the former mistake. Signed-off-by: Matt Kraai <kraai@ftbfs.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-24Merge branch 'ml/maint-grep-doc' into maintLibravatar Junio C Hamano1-5/+12
* ml/maint-grep-doc: grep documentation: clarify what files match
2010-02-23am: remove rebase-apply directory before gcLibravatar Jonathan Nieder1-2/+1
When git am does an automatic gc it doesn't clean up the rebase-apply directory until after this has finished. This means that if the user aborts the gc then future am or rebase operations will report that an existing operation is in progress, which is undesirable and confusing. Reported by Mark Brown <broonie@debian.org> through http://bugs.debian.org/570966 Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-23rerere: fix memory leak if rerere images can't be readLibravatar Bert Wesarg1-3/+6
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-23Documentation: mention conflict marker size argument (%L) for merge driverLibravatar Bert Wesarg1-1/+2
23a64c9e (conflict-marker-size: new attribute, 2010-01-16) introduced the new attribute and also pass the conflict marker size as %L to merge driver commands. This documents the substitution. Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-22tests: Fix race condition in t7006-pagerLibravatar Jonathan Nieder1-6/+6
Pagers that do not consume their input are dangerous: for example, $ GIT_PAGER=: git log $ echo $? 141 $ The only reason these tests were able to work before was that 'git log' would write to the pipe (and not fill it) before the pager had time to terminate and close the pipe. Fix it by using a program that consumes its input, namely wc (as suggested by Johannes). Reported-by: Johannes Sixt <j.sixt@viscovery.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-21sha1_file: be paranoid when creating loose objectsLibravatar Nicolas Pitre1-0/+9
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-21git-diff: add a test for git diff --quiet -wLibravatar Larry D'Anna1-0/+15
This patch adds two test cases for: 6977c25 git diff --quiet -w: check and report the status Signed-off-by: Larry D'Anna <larry@elder-gods.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-21hash-object: don't use mmap() for small filesLibravatar Dmitry Potapov1-0/+10
Using read() instead of mmap() can be 39% speed up for 1Kb files and is 1% speed up 1Mb files. For larger files, it is better to use mmap(), because the difference between is not significant, and when there is not enough memory, mmap() performs much better, because it avoids swapping. Signed-off-by: Dmitry Potapov <dpotapov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-21sha1_file: don't malloc the whole compressed result when writing out objectsLibravatar Nicolas Pitre1-14/+10
There is no real advantage to malloc the whole output buffer and deflate the data in a single pass when writing loose objects. That is like only 1% faster while using more memory, especially with large files where memory usage is far more. It is best to deflate and write the data out in small chunks reusing the same memory instead. For example, using 'git add' on a few large files averaging 40 MB ... Before: 21.45user 1.10system 0:22.57elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+828040outputs (0major+142640minor)pagefaults 0swaps After: 21.50user 1.25system 0:22.76elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+828040outputs (0major+104408minor)pagefaults 0swaps While the runtime stayed relatively the same, the number of minor page faults went down significantly. Signed-off-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-21t7006-pager: if stdout is not a terminal, make a new oneLibravatar Jonathan Nieder2-11/+82
Testing pagination requires (fake or real) access to a terminal so we can see whether the pagination automatically kicks in, which makes it hard to get good coverage when running tests without --verbose. There are a number of ways to work around that: - Replace all isatty calls with calls to a custom xisatty wrapper that usually checks for a terminal but can be overridden for tests. This would be workable, but it would require implementing xisatty separately in three languages (C, shell, and perl) and making sure that any code that is to be tested always uses the wrapper. - Redirect stdout to /dev/tty. This would be problematic because there might be no terminal available, and even if a terminal is available, it might not be appropriate to spew output to it. - Create a new pseudo-terminal on the fly and capture its output. This patch implements the third approach. The new test-terminal.perl helper uses IO::Pty from Expect.pm to create a terminal and executes the program specified by its arguments with that terminal as stdout. If the IO::Pty module is missing or not working on a system, the test script will maintain its old behavior (skipping most of its tests unless GIT_TEST_OPTS includes --verbose). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-20cherry_pick_list: quit early if one side is emptyLibravatar Thomas Rast1-0/+3
The --cherry-pick logic starts by counting the commits on each side, so that it can filter away commits on the bigger one. However, so far it missed an opportunity for optimization: it doesn't need to do any work if either side is empty. This in particular helps the common use-case 'git rebase -i HEAD~$n': it internally uses --cherry-pick, but since HEAD~$n is a direct ancestor the left side is always empty. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-20tests: Add tests for automatic use of pagerLibravatar Jonathan Nieder1-0/+163
Git’s automatic pagination support has some subtleties. Add some tests to make sure we don’t break: - when git will use a pager by default; - the effect of the --paginate and --no-pager options; - the effect of pagination on use of color; - how the choice of pager is configured. This does not yet test: - use of pager by scripted commands (git svn and git am); - effect of the pager.* configuration variables; - setting of the LESS variable. Some features involve checking whether stdout is a terminal, so many of these tests are skipped unless output is passed through to the terminal (i.e., unless $GIT_TEST_OPTS includes --verbose). The immediate purpose for these tests was to avoid making things worse after the breakage from my jn/editor-pager series (see commit 376f39, 2009-11-20). Thanks to Sebastian Celis <sebastian@sebastiancelis.com> for the report. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-20utf8.c: speculatively assume utf-8 in strbuf_add_wrapped_text()Libravatar René Scharfe1-6/+17
is_utf8() works by calling utf8_width() for each character at the supplied location. In strbuf_add_wrapped_text(), we do that anyway while wrapping the lines. So instead of checking the encoding beforehand, optimistically assume that it's utf-8 and wrap along until an invalid character is hit, and when that happens start over. This pays off if the text consists only of valid utf-8 characters. The following command was run against the Linux kernel repo with git 1.7.0: $ time git log --format='%b' v2.6.32 >/dev/null real 0m2.679s user 0m2.580s sys 0m0.100s $ time git log --format='%w(60,4,8)%b' >/dev/null real 0m4.342s user 0m4.230s sys 0m0.110s And with this patch series: $ time git log --format='%w(60,4,8)%b' >/dev/null real 0m3.741s user 0m3.630s sys 0m0.110s So the cost of wrapping is reduced to 70% in this case. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-20utf8.c: remove strbuf_write()Libravatar René Scharfe1-13/+5
The patch before the previous one made sure that all callers of strbuf_add_wrapped_text() supply a strbuf. Replace all calls of strbuf_write() with regular strbuf functions and remove it. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-20utf8.c: remove print_spaces()Libravatar René Scharfe1-9/+6
The previous patch made sure that strbuf_add_wrapped_text() (and thus strbuf_add_indented_text(), too) always get a strbuf. Make use of this fact by adding strbuf_addchars(), a small helper that adds a char the specified number of times to a strbuf, and use it to replace print_spaces(). Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-20utf8.c: remove print_wrapped_text()Libravatar René Scharfe3-9/+14
strbuf_add_wrapped_text() is called only from print_wrapped_text() without a strbuf (in which case it writes its results to stdout). At its only callsite, supply a strbuf, call strbuf_add_wrapped_text() directly and remove the wrapper function. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-20git-p4: fix bug in symlink handlingLibravatar Evan Powers1-3/+2
Fix inadvertent breakage from b932705 (git-p4: stream from perforce to speed up clones, 2009-07-30) in the code that strips the trailing '\n' from p4 print on a symlink. (In practice, contents is of the form ['target\n', ''].) Signed-off-by: Evan Powers <evan.powers@gmail.com> Acked-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-19t1450: fix testcases that were wrongly expecting failureLibravatar Thomas Rast1-8/+8
Almost exactly a year ago in 02a6552 (Test fsck a bit harder), I introduced two testcases that were expecting failure. However, the only bug was that the testcases wrote *blobs* because I forgot to pass -t tag to hash-object. Fix this, and then adjust the rest of the test to properly check the result. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-19Documentation: Fix indentation problem in git-commit(1)Libravatar Jacob Helwig1-3/+3
Ever since the "See linkgit:git-config[1]..." paragraph was added to the description for --untracked-files (d6293d1), the paragraphs for the following options were indented at the same level as the "See linkgit:git-config[1]" paragraph. This problem showed up in the manpages, but not in the HTML documentation. While this does fix the alignment of the options following --untracked-files in the manpage, the "See linkgit..." portion of the description does not retain its previous indentation level in the manpages, or HTML documentation. Signed-off-by: Jacob Helwig <jacob.helwig@gmail.com> Acked-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-19Merge branch 'jk/maint-rmdir-fix' into maintLibravatar Junio C Hamano2-1/+9
* jk/maint-rmdir-fix: rm: fix bug in recursive subdirectory removal
2010-02-18rm: fix bug in recursive subdirectory removalLibravatar Jeff King2-1/+9
If we remove a path in a/deep/subdirectory, we should try to remove as many trailing components as possible (i.e., subdirectory, then deep, then a). However, the test for the return value of rmdir was reversed, so we only ever deleted at most one level. The fix is in remove_path, so "apply" and "merge-recursive" also are fixed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-18Documentation: describe --thin more accuratelyLibravatar Stephen Boyd5-28/+36
The description for --thin was misleading and downright wrong. Correct it with some inspiration from the description of index-pack's --fix-thin and some background information from Nicolas Pitre <nico@fluxnic.net>. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-17docs: don't talk about $GIT_DIR/refs/ everywhereLibravatar Jeff King10-36/+39
It is misleading to say that we pull refs from $GIT_DIR/refs/*, because we may also consult the packed refs mechanism. These days we tend to treat the "refs hierarchy" as more of an abstract namespace that happens to be represented as $GIT_DIR/refs. At best, this is a minor inaccuracy, but at worst it can confuse users who then look in $GIT_DIR/refs and find that it is missing some of the refs they expected to see. This patch drops most uses of "$GIT_DIR/refs/*", changing them into just "refs/*", under the assumption that users can handle the concept of an abstract refs namespace. There are a few things to note: - most cases just dropped the $GIT_DIR/ portion. But for cases where that left _just_ the word "refs", I changed it to "refs/" to help indicate that it was a hierarchy. I didn't do the same for longer paths (e.g., "refs/heads" remained, instead of becoming "refs/heads/"). - in some cases, no change was made, as the text was explicitly about unpacked refs (e.g., the discussion in git-pack-refs). - In some cases it made sense instead to note the existence of packed refs (e.g., in check-ref-format and rev-parse). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>