Taylor Blau 62b3ec8a3f pack-bitmap.c: ensure pack validity for all reuse packs
Commit 44f9fd6496 (pack-bitmap.c: check preferred pack validity when
opening MIDX bitmap, 2022-05-24) prevents a race condition whereby the
preferred pack disappears between opening the MIDX bitmap and attempting
verbatim reuse out of its packs.

That commit forces open_midx_bitmap_1() to ensure the validity of the
MIDX's preferred pack, meaning that we have an open file handle on the
*.pack, ensuring that we can reuse bytes out of verbatim later on in the
process[^1].

But 44f9fd6496 was not extended to cover multi-pack reuse, meaning that
this same race condition exists for non-preferred packs during verbatim
reuse. Work around that race in the same way by only marking valid packs
as reuse-able. For packs that aren't reusable, skip over them but
include the number of objects they have to ensure we allocate a large
enough 'reuse' bitmap (e.g. if a pack in the middle of the MIDX
disappeared but we still want to reuse later packs).

Since we're ensuring the validity of these packs within the verbatim
reuse code, we no longer have to special-case the preferred pack and
open it within the open_midx_bitmap_1() function.

An alternative approach to the one taken here would be to open all
MIDX'd packs from within open_midx_bitmap_1(). But that would be both
slower and make the bitmaps less useful, since we can still perform some
pack reuse among the packs that still exist when the *.bitmap is opened.

After applying this patch, we can simulate the new behavior after
instrumenting Git like so:

    diff --git a/packfile.c b/packfile.c
    index 9560f0a33c..aedce72524 100644
    --- a/packfile.c
    +++ b/packfile.c
    @@ -557,6 +557,11 @@ static int open_packed_git_1(struct packed_git *p)
     		; /* nothing */

     	p->pack_fd = git_open(p->pack_name);
    +	{
    +		const char *delete = getenv("GIT_RACILY_DELETE");
    +		if (delete && !strcmp(delete, pack_basename(p)))
    +			return -1;
    +	}
     	if (p->pack_fd < 0 || fstat(p->pack_fd, &st))
     		return -1;
     	pack_open_fds++;

and adding the following test:

    test_expect_success 'disappearing packs' '
            git init disappearing-packs &&
            (
                    cd disappearing-packs &&

                    git config pack.allowPackReuse multi &&

                    test_commit A &&
                    test_commit B &&
                    test_commit C &&

                    A="$(echo "A" | git pack-objects --revs $packdir/pack-A)" &&
                    B="$(echo "A..B" | git pack-objects --revs $packdir/pack-B)" &&
                    C="$(echo "B..C" | git pack-objects --revs $packdir/pack-C)" &&

                    git multi-pack-index write --bitmap --preferred-pack=pack-A-$A.idx &&

                    test_pack_objects_reused_all 9 3 &&

                    test_env GIT_RACILY_DELETE=pack-A-$A.pack \
                            test_pack_objects_reused_all 6 2 &&
                    test_env GIT_RACILY_DELETE=pack-B-$B.pack \
                            test_pack_objects_reused_all 6 2 &&
                    test_env GIT_RACILY_DELETE=pack-C-$C.pack \
                            test_pack_objects_reused_all 6 2

            )
    '

Note that we could relax the single-pack version of this which was most
recently addressed in dc1daacdcc (pack-bitmap: check pack validity when
opening bitmap, 2021-07-23), but only partially. Because we still need
to know the object count in the pack, we'd still have to open the pack's
*.idx, so the savings there are marginal.

Note likewise that we add a new "if (!packs_nr)" early return in the
pack reuse code to avoid a potentially expensive allocation on the
'reuse' bitmap in the case that no packs are available for reuse.

[^1]: Unless we run out of open file handles. If that happens and we are
  forced to close the only open file handle of a file that has been
  removed from underneath us, there is nothing we can do.

Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-12-18 09:51:09 -08:00
2024-09-16 15:27:08 -07:00
2024-10-04 14:21:44 -07:00
2024-05-24 11:40:44 -07:00
2024-10-04 14:21:40 -07:00
2023-11-26 10:07:06 +09:00
2024-09-20 14:40:41 -07:00
2024-09-06 09:31:15 -07:00
2024-09-25 10:37:10 -07:00
2024-09-23 10:35:07 -07:00
2024-06-17 15:55:55 -07:00
2024-07-08 14:53:10 -07:00
2023-12-26 12:04:32 -08:00
2024-07-08 14:53:10 -07:00
2024-09-23 10:35:07 -07:00
2024-09-03 09:15:00 -07:00
2024-09-16 10:46:00 -07:00
2024-06-14 10:26:33 -07:00
2024-06-14 10:26:33 -07:00
2024-01-23 10:40:10 -08:00
2024-06-14 10:26:33 -07:00
2024-06-14 10:26:33 -07:00
2024-08-23 09:02:33 -07:00
2024-04-05 15:21:14 -07:00
2024-10-02 07:46:26 -07:00
2024-10-02 07:46:26 -07:00
2024-09-19 13:46:00 -07:00
2024-06-14 10:26:33 -07:00
2024-10-02 07:46:26 -07:00
2024-08-08 09:36:53 -07:00
2023-04-17 21:15:56 +02:00
2024-09-19 13:46:00 -07:00
2024-09-19 13:46:00 -07:00
2024-10-06 15:56:06 -07:00
2024-10-02 07:46:26 -07:00
2023-11-26 10:07:05 +09:00
2024-09-27 08:25:36 -07:00
2023-06-28 14:06:39 -07:00
2024-09-23 10:35:09 -07:00
2024-10-02 07:46:26 -07:00
2023-06-28 14:06:39 -07:00
2024-04-19 12:38:50 +02:00
2023-11-26 10:07:05 +09:00
2023-11-26 10:07:05 +09:00
2023-11-26 10:07:05 +09:00
2023-11-26 10:07:05 +09:00
2024-06-14 10:26:33 -07:00
2024-08-09 08:47:34 -07:00
2024-09-06 10:38:49 -07:00
2024-07-08 14:53:10 -07:00
2024-02-26 15:34:01 -08:00
2024-07-08 14:53:10 -07:00
2024-07-08 14:53:10 -07:00
2024-06-14 10:26:33 -07:00
2024-06-14 10:26:33 -07:00
2024-07-25 09:03:00 -07:00
2024-05-24 11:40:42 -07:00
2024-05-24 11:40:42 -07:00
2024-09-25 10:37:12 -07:00
2023-11-26 10:07:05 +09:00
2024-08-09 08:47:34 -07:00
2024-09-19 13:46:00 -07:00
2024-05-11 17:22:17 +02:00
2024-09-19 13:46:01 -07:00
2024-04-05 15:21:14 -07:00
2024-09-25 10:37:11 -07:00
2024-09-25 10:37:12 -07:00
2024-09-16 15:19:05 -07:00
2024-06-14 10:26:33 -07:00
2024-06-14 10:26:33 -07:00
2024-09-19 13:46:12 -07:00
2024-09-19 13:46:12 -07:00
2024-09-20 11:16:30 -07:00
2024-08-28 10:31:26 -07:00
2024-09-25 10:37:12 -07:00
2023-11-26 10:07:05 +09:00
2024-06-14 10:26:33 -07:00
2023-09-15 17:08:46 -07:00
2024-06-12 13:37:15 -07:00
2024-10-02 07:46:26 -07:00
2024-05-17 10:33:39 -07:00
2023-03-17 14:03:09 -07:00
2024-05-23 11:04:27 -07:00
2024-06-14 10:26:33 -07:00
2023-06-28 14:06:39 -07:00
2024-04-05 15:16:27 -07:00
2023-11-26 10:07:05 +09:00
2024-08-09 08:47:34 -07:00
2023-04-04 14:28:27 -07:00
2024-06-24 16:39:15 -07:00
2024-09-04 08:03:24 -07:00
2023-05-17 10:11:41 -07:00
2024-06-14 10:26:33 -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 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):

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