Re: [PATCH v4 07/12] rebase: add --update-refs option

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux