Re: [PATCH] prune-packed: remove USE_THE_REPOSITORY_VARIABLE

[Junio C Hamano <gitster@pobox.com>]

Shashank S <shashu8660@gmail.com> writes:

>> 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.