SZEDER Gábor e8b3b2e275 t/lib-httpd: avoid occasional failures when checking access.log
The last test of 't5561-http-backend.sh', 'server request log matches
test results' may fail occasionally, because the order of entries in
Apache's access log doesn't match the order of requests sent in the
previous tests, although all the right requests are there.  I saw it
fail on Travis CI five times in the span of about half a year, when
the order of two subsequent requests was flipped, and could trigger
the failure with a modified Git.  However, I was unable to trigger it
with stock Git on my machine.  Three tests in
't5541-http-push-smart.sh' and 't5551-http-fetch-smart.sh' check
requests in the log the same way, so they might be prone to a similar
occasional failure as well.

When a test sends a HTTP request, it can continue execution after
'git-http-backend' fulfilled that request, but Apache writes the
corresponding access log entry only after 'git-http-backend' exited.
Some time inevitably passes between fulfilling the request and writing
the log entry, and, under unfavourable circumstances, enough time
might pass for the subsequent request to be sent and fulfilled by a
different Apache thread or process, and then Apache writes access log
entries racily.

This effect can be exacerbated by adding a bit of variable delay after
the request is fulfilled but before 'git-http-backend' exits, e.g.
like this:

  diff --git a/http-backend.c b/http-backend.c
  index f3dc218b2..bbf4c125b 100644
  --- a/http-backend.c
  +++ b/http-backend.c
  @@ -709,5 +709,7 @@ int cmd_main(int argc, const char **argv)
   					   max_request_buffer);

   	cmd->imp(&hdr, cmd_arg);
  +	if (getpid() % 2)
  +		sleep(1);
   	return 0;
   }

This delay considerably increases the chances of log entries being
written out of order, and in turn makes t5561's last test fail almost
every time.  Alas, it doesn't seem to be enough to trigger a similar
failure in t5541 and t5551.

So, since we can't just rely on the order of access log entries always
corresponding the order of requests, make checking the access log more
deterministic by sorting (simply lexicographically) both the stripped
access log entries and the expected entries before the comparison with
'test_cmp'.  This way the order of log entries won't matter and
occasional out-of-order entries won't trigger a test failure, but the
comparison will still notice any unexpected or missing log entries.

OTOH, this sorting will make it harder to identify from which test an
unexpected log entry came from or which test's request went missing.
Therefore, in case of an error include the comparison of the unsorted
log enries in the test output as well.

And since all this should be performed in four tests in three test
scripts, put this into a new helper function 'check_access_log' in
't/lib-httpd.sh'.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-12 10:40:31 -07:00
2018-05-22 14:10:49 +09:00
2018-05-22 14:12:02 +09:00
2017-07-10 14:24:36 -07:00
2017-07-06 18:14:44 -07:00
2017-06-27 10:35:49 -07:00
2017-06-24 14:28:41 -07:00
2018-05-22 14:10:49 +09:00
2017-06-24 14:28:41 -07:00
2017-06-24 14:28:41 -07:00
2017-03-13 15:28:54 -07:00
2017-06-24 14:28:41 -07:00
2017-07-31 13:05:15 -07:00
2017-05-25 13:08:23 +09:00
2017-05-08 15:12:57 +09:00
2017-05-08 15:12:57 +09:00
2017-08-03 11:08:10 -07:00
2017-05-29 12:34:43 +09:00
2017-05-02 10:46:41 +09:00
2017-07-17 14:54:56 -07:00
2018-05-22 14:10:49 +09:00
2017-01-25 14:42:37 -08:00
2017-07-17 14:54:56 -07:00
2017-06-22 14:15:20 -07:00
2017-08-04 12:40:37 -07:00
2017-06-24 14:28:41 -07:00
2017-06-24 14:28:41 -07:00
2017-06-19 12:38:44 -07:00
2017-06-22 14:15:21 -07:00
2017-06-24 14:28:41 -07:00
2017-06-24 14:28:41 -07:00
2017-03-31 08:33:56 -07:00
2017-03-31 08:33:56 -07:00
2016-07-01 12:44:57 -07:00
2016-07-01 12:44:57 -07:00
2018-05-22 14:10:49 +09:00
2018-05-22 14:10:49 +09:00
2018-05-22 14:12:02 +09:00
2017-06-24 14:28:41 -07:00
2017-07-12 15:18:23 -07:00
2017-01-30 14:17:00 -08:00
2016-12-07 11:31:59 -08:00
2017-06-24 14:28:41 -07:00
2016-07-29 11:05:07 -07:00
2016-07-29 11:05:07 -07:00
2017-06-24 14:28:41 -07:00
2017-06-24 14:28:41 -07:00
2017-02-08 15:39:55 -08:00
2017-01-30 14:17:00 -08:00
2017-05-29 12:34:43 +09:00
2017-06-24 14:28:41 -07:00
2017-06-30 13:11:54 -07:00
2018-05-22 14:10:49 +09:00
2017-06-27 10:35:49 -07:00
2016-07-28 11:26:03 -07:00
2016-07-28 11:26:03 -07:00
2017-05-29 12:34:43 +09:00
2018-05-22 14:10:49 +09:00
2017-07-17 14:54:56 -07:00
2018-05-22 14:12:02 +09:00
2017-08-02 15:45:20 -07:00
2017-10-03 08:42:57 +09:00
2017-06-27 10:35:49 -07:00
2017-03-31 08:33:56 -07:00
2017-06-13 13:47:09 -07:00
2017-07-12 15:18:23 -07:00
2017-03-31 08:33:56 -07:00
2017-05-22 10:20:46 +09:00
2017-05-22 10:20:46 +09:00
2017-06-24 14:28:41 -07:00
2017-07-17 14:54:56 -07:00
2018-05-22 14:10:49 +09:00
2018-05-22 14:10:49 +09:00
2017-09-22 10:59:52 +09:00
2017-10-02 13:14:33 +09:00
2017-05-29 12:34:43 +09:00
2016-08-05 09:28:17 -07:00
2017-06-24 14:28:41 -07:00
2017-06-24 14:28:41 -07:00
2017-06-24 14:28:41 -07:00
2017-06-24 14:28:41 -07:00
2018-05-21 23:50:11 -04:00
2018-05-21 23:50:11 -04:00
2017-06-24 14:28:41 -07:00

Git - fast, scalable, distributed revision control system

Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals.

Git is an Open Source project covered by the GNU General Public License version 2 (some parts of it are under different licenses, compatible with the GPLv2). It was originally written by Linus Torvalds with help of a group of hackers around the net.

Please read the file INSTALL for installation instructions.

Many Git online resources are accessible from https://git-scm.com/ including full documentation and Git related tools.

See Documentation/gittutorial.txt to get started, then see Documentation/giteveryday.txt for a useful minimum set of commands, and Documentation/git-.txt for documentation of each command. If git has been correctly installed, then the tutorial can also be read with man gittutorial or git help tutorial, and the documentation of each command with man git-<commandname> or git help <commandname>.

CVS users may also want to read Documentation/gitcvs-migration.txt (man gitcvs-migration or git help cvs-migration if git is installed).

The user discussion and development of Git take place on the Git mailing list -- everyone is welcome to post bug reports, feature requests, comments and patches to git@vger.kernel.org (read Documentation/SubmittingPatches for instructions on patch submission). To subscribe to the list, send an email with just "subscribe git" in the body to majordomo@vger.kernel.org. The mailing list archives are available at https://public-inbox.org/git/, http://marc.info/?l=git and other archival sites.

The maintainer frequently sends the "What's cooking" reports that list the current status of various development topics to the mailing list. The discussion following them give a good reference for project status, development direction and remaining tasks.

The name "git" was given by Linus Torvalds when he wrote the very first version. He described the tool as "the stupid content tracker" and the name as (depending on your mood):

  • random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant.
  • stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang.
  • "global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
  • "goddamn idiotic truckload of sh*t": when it breaks
Description
No description provided
Readme 577 MiB
Languages
C 50.4%
Shell 38.7%
Perl 4.4%
Tcl 3.1%
Python 0.8%
Other 2.4%