Re: [PATCH] rebase --update-refs: avoid unintended ref deletion

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

 



On Fri, Nov 04, 2022 at 09:57:36AM -0700, Victoria Dye wrote:
> However, because 'write_update_refs_state()' will not update the state if
> the 'refs_to_oids' list was empty, removing *all* 'update-ref' lines will
> result in the state remaining unchanged from how it was initialized (with
> all refs' "after" OID being null). Then, when the ref update is applied, all
> refs will be updated to null and consequently deleted.

Good catch.

I wonder, though: should we only add pending ref updates to the
update-refs state after we reach that point in the sequence?

IOW: there is no world where deleting an update-refs command means to
drop the affected branch, right? So the initial state would be an empty
list, which would cause us to not update any references.

Then as we proceed through the rebase, we accumulate update-refs
commands, and know their after_oid immediately. Then when we're done, we
can process the update-refs commands for the branches that we do have.

The more I think about this, the more that I am convinced that the bug
is in how we initialize the pending list, not our treatment of it later
on.

The bug fix works as-is, but I can't help wonder if the above approach
might be more direct.

Thanks,
Taylor



[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