From: Shashank S <shashu8660@gmail.com>
Date: Tue, 20 Oct 2026 16:27:23 GMT
Subject: Re: [PATCH] prune-packed: remove USE_THE_REPOSITORY_VARIABLE
Message-ID: <CANHmUQR2RG+4AGvxN2mPZoBeNn4HUpTivXm5bck0yVXyb+RuOg@mail.gmail.com>
In-Reply-To: <xmqqqzhl2yfq.fsf@gitster.g>

On Tue, 20 Oct 2026 at 02:35, Junio C Hamano <gitster@pobox.com> wrote:

>
> Shashank S <shashu8660@gmail.com> writes:
>
> > 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.

Thank you for the correction and the detailed explanation.

I had not considered the parse_options() and the behavior of the -h
flags outside of a working tree. It is great to know that while
RUN_SETUP isn't an absolute guarantee against NULL on its own (unlike
RUN_SETUP_GENTLY), the fact that parse_options() exits before my
modified function calls ensures repo is never dereferenced when NULL.

I appreciate you taking the time to explain this to me.

Thanks.