Re: [PATCH] prune-packed: remove USE_THE_REPOSITORY_VARIABLE

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 19, 2026, 21:05 UTC
Message-ID: <xmqqqzhl2yfq.fsf@gitster.g>
In-Reply-To: <CANHmUQTj8nR1GmPD2FW3+yfsgdgNh_vwRCcxRhS8GcY4VHDb8g@mail.gmail.com>

Shashank S <shashu8660@gmail.com> writes:

Show 17 quoted lines

>> The question isn't really whether we can safely remove the UNUSED macro.
>> The question is rather whether we can assume that `repo` always points
>> to a proper repository. And for that you need to research whether these
>> commands can be invoked outside of a repository, because if so the repo
>> may be `NULL`.
>
> I have checked git.c file in that file I went through this commands .
> prune , prune-packed and repack which are .
> { "prune", cmd_prune, RUN_SETUP },
> { "prune-packed", cmd_prune_packed, RUN_SETUP },
> { "repack", cmd_repack, RUN_SETUP },
> All this commands are all registered with a special flags '
> RUN_SETUP'. This flags search for .git folder . If it finds a .git
> folder Git successfully initializes the repo struct and passes that to
> valid pointer to your builtin . If it does not find a .git folder (if
> they ran it outside the repository) Git immediately stops and shows
> the error . It never run the code .

The analysis is not entirely correct. Assuming that your system administrator is not insane enough and did not make the entire filesystem as a working tree of a repository,

    $ cd / && git repack -h

does call cmd_repack() with "repo" set to NULL.

The call to parse_options() will give the short help and exit. Becaues the references to "repo" you added all happen after the code already called parse_options(), your update will not make the code dereference NULL. Some subcommands with tricky call sequence into parse_options() _may_ have to be a bit more careful than just checking "are we using RUN_SETUP?". Of course RUN_SETUP_GENTLY is an explicit sign that you have to be prepared to see NULL in "repo".

Thanks.