t5551: put many-tags case into its own repo Most of the t5551 http fetch tests use a handful of refs. But there are a few test cases which check our handling of large numbers of refs. These tests use the same server-side repo, so all subsequent tests end up having to consider those extra refs, too. The result is that the test script is a bit slower than it needs to be. In a normal run, moving the "2,000 tags" test into its own repo drops my runtime for the whole script from ~2.7s to ~1.9s. This is a modest gain, but when we add the "--long" flag it gets much bigger. There we trigger a test (marked with EXPENSIVE) that adds 100,000 tags, and the script runtime jumps to ~95s. But if we use the same "many tags" repo for that, our runtime drops to just ~37s. This is a pretty easy win to drop the cost of the script. It may even be a larger gain on a heavily loaded system, since one of the main costs here is unpacked refs, which are heavy on system time and I/O costs. It's possible we are reducing test coverage, since all of those other tests were inadvertently using large ref advertisements (and thus could have uncovered some unexpected interaction). But that seems somewhat unlikely; the tests targeted at the large number of refs are doing roughly similar things to the other tests. Note that the real performance culprit is the 100k-tag --long test, not the 2k-tag one. So we could just let the 100k one use its own repo, and keep the 2k tags in the main repo. But since these two tests are somewhat interlinked, it's easier to just move them both (and it does provide a small gain even for the 2000-tag test). I also notice that the 2000-tag test is gated on the CMDLINE_LIMIT prereq, and without that the later EXPENSIVE test will fail (since we won't have a too-many-refs clone). Nobody seems to have noticed or complained after many years, and I left it alone for this patch. Signed-off-by: Jeff King <peff@peff.net> [jc: made the new "many-tags.git" bare to match the original "repo.git"] Signed-off-by: Junio C Hamano <gitster@pobox.com>
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.adoc to get started, then see Documentation/giteveryday.adoc for a useful minimum set of commands, and Documentation/git-<commandname>.adoc 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.adoc (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 and Documentation/CodingGuidelines).
Those wishing to help with error message, usage and informational message string translations (localization l10) should see po/README.md (a po file is a Portable Object file that holds the translations).
To subscribe to the list, send an email to git+subscribe@vger.kernel.org (see https://subspace.kernel.org/subscribing.html for details). The mailing list archives are available at https://lore.kernel.org/git/, https://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):