René Scharfe 1aa589922b test-mergesort: add unriffle mode
Add a mode that turns sorted items into adversarial input for mergesort.
Do that by running mergesort in reverse and rearranging the items in
such a way that each merge needs the maximum number of operations to
undo it.

To riffle is a card shuffling technique and involves splitting a deck
into two and then to interleave them.  A perfect riffle takes one card
from each half in turn.  That's similar to the most expensive merge,
which has to take one item from each sublist in turn, which requires the
maximum number of comparisons (n-1).

So unriffle does that in reverse, i.e. it generates the first sublist
out of the items at even indexes and the second sublist out of the items
at odd indexes, without changing their order in any other way.  Done
recursively until we reach the trivial sublist length of one, this
twists the list into an order that requires the maximum effort for
mergesort to untangle.

As a baseline, here are the rand distributions with the highest number
of comparisons from "test-tool mergesort test":

   $ t/helper/test-tool mergesort test | awk '
      NR > 1 && $1 != "rand" {next}
      $7 > max[$3] {max[$3] = $7; line[$3] = $0}
      END {for (n in line) print line[n]}
   '

distribut mode                    n        m get_next set_next  compare verdict
rand      copy                  100       32     1184      700      569 OK
rand      reverse_1st_half     1023      256    16373    10230     8976 OK
rand      reverse_1st_half     1024      512    16384    10240     8993 OK
rand      dither               1025       64    18454    11275     9970 OK

And here are the most expensive ones overall:

   $ t/helper/test-tool mergesort test | awk '
      $7 > max[$3] {max[$3] = $7; line[$3] = $0}
      END {for (n in line) print line[n]}
   '

distribut mode                    n        m get_next set_next  compare verdict
stagger   reverse               100       64     1184      700      580 OK
sawtooth  unriffle             1023     1024    16373    10230     9179 OK
sawtooth  unriffle             1024     1024    16384    10240     9217 OK
stagger   unriffle             1025     2048    18454    11275    10241 OK

The sawtooth distribution with m>=n generates a sorted list.  The
unriffle mode is designed to turn that into adversarial input for
mergesort, and that checks out for n=1023 and n=1024, where it produces
the list that requires the most comparisons.

Item counts that are not powers of two have other winners, and that's
because unriffle recursively splits lists into equal-sized halves, while
llist_mergesort() splits them into the biggest power of two smaller than
n and the rest, e.g. for n=1025 it sorts the first 1024 separately and
finally merges them to the last item.

So unriffle mode works as designed for the intended use case, but to
consistently generate adversarial input for unbalanced merges we need
something else.

Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-01 12:43:08 -07:00
2021-02-12 15:51:12 +01:00
2021-02-12 15:51:13 +01:00
2020-11-09 14:06:25 -08:00
2021-10-01 12:43:08 -07:00
2020-08-13 11:02:15 -07:00
2020-12-08 15:11:21 -08:00
2020-03-05 10:43:02 -08:00
2020-12-08 15:11:17 -08:00
2020-12-18 15:15:18 -08:00
2019-11-18 15:21:28 +09:00
2020-11-21 15:14:38 -08:00
2020-09-02 14:39:25 -07:00
2020-11-18 13:32:53 -08:00
2020-08-11 18:04:11 -07:00
2021-02-12 15:51:12 +01:00
2020-08-10 10:23:57 -07:00
2020-09-30 12:53:47 -07:00
2019-12-01 09:04:36 -08:00
2020-07-06 22:09:13 -07:00
2020-08-24 14:54:31 -07:00
2020-11-12 09:40:06 -08:00
2020-07-30 19:18:06 -07:00
2020-12-18 15:15:18 -08:00
2020-11-02 13:17:44 -08:00
2020-11-21 15:14:38 -08:00
2020-08-27 14:04:49 -07:00
2020-07-30 19:18:06 -07:00
2020-07-28 15:02:17 -07:00
2020-09-03 12:37:04 -07:00
2020-03-24 15:04:43 -07:00
2020-08-10 10:23:57 -07:00
2020-11-09 14:06:25 -08:00
2021-02-12 15:51:12 +01:00
2021-02-12 15:51:13 +01:00
2020-07-30 19:18:06 -07:00
2019-11-18 15:21:28 +09:00
2020-11-30 13:55:54 -08:00
2020-07-30 19:18:06 -07:00
2020-06-25 12:27:47 -07:00
2020-12-14 15:01:03 -08:00
2019-11-18 15:21:28 +09:00
2020-07-30 19:18:06 -07:00
2020-07-28 15:02:17 -07:00
2021-01-06 13:53:32 -08:00
2020-05-01 13:39:55 -07:00
2020-11-21 15:14:38 -08:00
2020-11-25 15:24:52 -08:00
2020-12-08 15:11:18 -08:00
2020-08-28 14:07:09 -07:00
2020-07-30 19:18:06 -07:00
2019-12-16 13:08:39 -08:00
2020-07-06 22:09:13 -07:00
2020-03-24 15:04:44 -07:00
2020-03-24 15:04:44 -07:00
2020-12-14 10:21:36 -08:00
2020-10-27 15:09:50 -07:00
2021-02-12 15:51:13 +01:00
2020-10-27 15:09:49 -07:00
2020-04-29 16:15:27 -07:00
2021-02-12 15:51:12 +01:00
2020-11-21 15:14:38 -08:00
2020-07-28 15:02:17 -07:00
2020-08-11 18:04:11 -07:00
2020-09-02 14:39:25 -07:00
2019-11-13 10:09:10 +09:00
2019-11-18 15:21:29 +09:00
2020-07-30 19:18:06 -07:00
2020-07-30 19:18:06 -07:00
2021-02-12 15:49:35 +01:00
2020-07-30 19:18:06 -07:00
2021-02-12 15:50:14 +01:00
2020-07-28 15:02:17 -07:00
2020-11-02 13:17:46 -08:00
2020-10-05 14:01:52 -07:00
2020-10-05 14:01:52 -07:00

Build status

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-<commandname>.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://lore.kernel.org/git/, http://marc.info/?l=git and other archival sites.

Issues which are security relevant should be disclosed privately to the Git Security mailing list git-security@googlegroups.com.

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 279 MiB
Languages
C 50.5%
Shell 38.7%
Perl 4.5%
Tcl 3.2%
Python 0.8%
Other 2.1%