On 7/19/2022 12:44 PM, Junio C Hamano wrote:
> Derrick Stolee <derrickstolee@xxxxxxxxxx> writes:
>
>> On 7/18/2022 3:35 PM, Junio C Hamano wrote:
>>> Derrick Stolee <derrickstolee@xxxxxxxxxx> writes:
>>>
>>>> ... I think I should use "branches" here, but
>>>> keep the name "--update-refs". The biggest reason is that it provides
>>>> a nice parallel with the "update-ref" sequencer command. This command
>>>> allows updating _any_ ref, such as lightweight tags in refs/tags/*
>>>> or even refs in refs/my/namespace/*.
>>>>
>>>> The --update-refs option doesn't create the commands to update tags
>>>> or refs in places other than refs/heads/*.
>>>
>>> I guess it would make the choice of "branch" the most appropriate.
>>>
>>> I was hoping that we can repoint refs in private namespaces that are
>>> not branches with the option. But as long as the underlying
>>> "update-ref" instruction can be used by advanced users, that is OK.
>>
>> I would like to keep the --update-refs name for a couple reasons:
>
> I do not think anybody proposed to change the name of that option.
>
> I was reacting to your "I should use branches here", with the
> understanding that "here" is this place where you used "local refs".
>
>>> + OPT_BOOL(0, "update-refs", &options.update_refs,
>>> + N_("update local refs that point to commits "
>
> If "rebase --update-refs" uses "update-ref" insn (which is capable
> of repointing non-branch refs) only for local branches, then the
> help text for the "--update-refs" option can safely say "update
> local branches" without being inaccurate. That is where my "branch
> is the most appropriate" comes from.
Thanks for the clarification. Sorry for misunderstanding.
Thanks,
-Stolee
