git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: rebase -i --update-refs can lead to deletion of branches

From
PWPhillip Wood <phillip.wood123@gmail.com>
Date
Nov 4, 2022, 10:40 UTC
Message-ID
<c195b67c-4dbc-a8b8-8513-2664e1ca2404@dunelm.org.uk>
In-Reply-To
<123628cc-1410-aaa0-0151-2dff35bd1855@github.com>
Hi Victoria
On 04/11/2022 00:31, Victoria Dye wrote:
Show 30 quoted lines
> herr.kaste wrote:
>> Now, I should just have not used `--update-refs` in the first place but anyway
>> I decide late that I rather don't want to update "master" etc. and it should
>> probably not delete the local refs.
>>
> 
> Agreed, this doesn't seem like desired behavior - the opposite of "update
> the ref" isn't "delete the ref". ;)
> 
> The reason it's happening is because, when '--update-refs' is used, the
> rebase starts by constructing a list of 'update_ref_record's for each of the
> refs that *could* be updated. Each item in that list contains the
> corresponding ref's "before" commit OID (i.e., what it currently points to)
> and initializes the "after" OID to null. When an 'update-ref' line is
> encountered in the 'rebase-todo', the "after" OID is updated with the
> newly-rebased value. However, if an 'update-ref' line is removed from the
> 'rebase-todo', the "after" value is never updated. Then, when the rebase
> finishes and the ref state data is applied, all of the entries with null
> "after" OIDs are deleted.
> 
> The three options for a fix I can think of are:
> 
>    1. initialize the "after" OID to the value of "before".
>    2. don't update refs with a null "after" OID.
>    3. initialize the "after" OID to the value of "before", don't update the
>       ref if "before" == "after".
> 
> I think #3 is the best option, since it avoids the unnecessary updates of #1
> and leaves a cleaner path to a 'delete-ref' option (like the one proposed
> elsewhere in the thread [1]) than #2. I'll send a patch shortly.

We should be removing the entry entirely if the user removes it from the todo-list see b3b1a21d1a (sequencer: rewrite update-refs as user edits todo list, 2022-07-19) where the commit message says

1. If a '<ref>/<before>/<after>' triple in the update-refs file does not
    have a matching 'update-ref <ref>' command in the todo-list _and_ the
    <after> value is the null OID, then remove that triple. Here, the
    user removed the 'update-ref <ref>' command before it was executed,
    since if it was executed then the <after> value would store the
    commit at that position.

I think that is the best approach but it seems the implementation isn't actually doing that.

Best Wishes
Phillip
Show 5 quoted lines
> [1] https://lore.kernel.org/git/CA+JQ7M-GbBTHZZ9xOLR=FitWFpUnkfuep9kSfNPxuSbJbKteGw@mail.gmail.com/
> 
> Thanks for reporting!
> - Victoria
> 
Previous: Victoria DyeNext: Victoria Dye
Message 7 of 17 in “rebase -i --update-refs can lead to deletion of branches”
  1. herr.kasteOct 20, 2022
  2. Erik Cervin EdinOct 20, 2022
  3. Phillip WoodNov 3, 2022
  4. herr.kasteNov 3, 2022
  5. Erik Cervin EdinNov 3, 2022
  6. Victoria DyeNov 4, 2022
  7. Phillip WoodNov 4, 2022
  8. Victoria DyeNov 4, 2022
  9. rebase --update-refs: avoid unintended ref deletionVictoria Dye, Nov 4, 2022
  10. Taylor BlauNov 4, 2022
  11. Phillip WoodNov 4, 2022
  12. Phillip WoodNov 4, 2022
  13. Derrick StoleeNov 7, 2022
  14. rebase --update-refs: avoid unintended ref deletionVictoria Dye, Nov 7, 2022
  15. Taylor BlauNov 7, 2022
  16. Derrick StoleeNov 7, 2022
  17. Phillip WoodNov 8, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.