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

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

From
Derrick Stolee <derrickstolee@github.com>
Date
Nov 7, 2022, 02:39 UTC
Message-ID
<20221c91-e473-c66a-a0bd-b650a6626e31@github.com>
In-Reply-To
<6c022318-afc0-2ad7-b29c-ccb87f2f2e94@dunelm.org.uk>
On 11/4/22 4:12 PM, Phillip Wood wrote:
Show 16 quoted lines
> Hi Victoria
> 
> On 04/11/2022 16:57, Victoria Dye wrote:
>> In b3b1a21d1a5 (sequencer: rewrite update-refs as user edits todo list,
>> 2022-07-19), the 'todo_list_filter_update_refs()' step was added to handle
>> the removal of 'update-ref' lines from a 'rebase-todo'. Specifically, it
>> removes potential ref updates from the "update refs state" if a ref does not
>> have a corresponding 'update-ref' line.
>>
>> 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.
> 
> Thanks for taking the time to track down the cause of this bug and fix it.
I will add my thanks, too. Thanks for jumping in when I could not!
Show 12 quoted lines
>> To fix this, add a 'force_if_empty' flag to allow writing the update refs
>> state even if 'refs_to_oids' is empty. The three usages of
>> 'write_update_refs_state()' are updated as follows:
>>
>> - in 'todo_list_filter_update_refs()': force_if_empty is 1 because update
>>    ref entries are removed here. This setting fixes the ref deletion issue.
>> - in 'do_update_ref()': force_if_empty is 0, since this method only modifies
>>    (does not add or delete) ref update entries.
>> - in 'todo_list_add_update_ref_commands()': force_if_empty is 0, since this
>>    method strictly adds ref update entries.
> 
> I think not writing the list if it is empty is just an optimization to avoid creating an empty file. I wonder if it would be simpler to unlink() any existing file if write_update_refs_state() is called with an empty list rather than adding the force flag.

I agree that an unlink() is the best option, barring one point (that I will mention below).

Show 24 quoted lines
>> +test_expect_success '--update-refs: do not delete refs if all update-ref are removed' '
>> +    git checkout -b test-refs-not-removed no-conflict-branch &&
>> +    git branch -f base HEAD~4 &&
>> +    git branch -f first HEAD~3 &&
>> +    git branch -f second HEAD~3 &&
>> +    git branch -f third HEAD~1 &&
>> +    git branch -f tip &&
>> +    (
>> +        set_cat_todo_editor &&
>> +        test_must_fail git rebase -i --update-refs base >todo.raw &&
>> +        sed -e "/^update-ref/d" <todo.raw >todo
>> +    ) &&
>> +    (
>> +        set_replace_editor todo &&
>> +        git rebase -i --update-refs base
>> +    ) &&
>> +
>> +    test_cmp_rev HEAD~3 refs/heads/first &&
>> +    test_cmp_rev HEAD~3 refs/heads/second &&
>> +    test_cmp_rev HEAD~1 refs/heads/third &&
>> +    test_cmp_rev HEAD refs/heads/tip &&
>> +    test_cmp_rev HEAD refs/heads/no-conflict-branch
>> +'
>> +

This is a great test! I'm glad that it handles the existing case. I think the only case that might be interesting is to make the rebase actually create new commits and show that the removed refs are no longer in the history of the new branch, but are instead reachable from the older tip.

For this test, we could create a 'fixup!' to 'first' and use --autosquash to generate new commits. At the end, we can compare first, second, and third to different ancestors of refs/heads/no-conflict-branch _and_ guarantee that no-conflict-branch did not move. Or:

  git rev-parse first second third no-conflict-branch >expect-oids &&
  ...do the rebase...
  git rev-parse first second third no-conflict-branch >actual-oids &&
  test_cmp expect-oids actual-oids
should work to guarantee these refs were not updated.

I wonder if anything interesting happens if after we remove the update-ref commands we have a 'break' command and then re-insert some of the commands. Will things like the unlink() direction cause a problem then?

Anyway, here is a potential diff on top of your patch that adds these modifications to the test. They work with your implementation changes, but I also didn't try the unlink() modification.

--- >8 ---
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index e7d3721ece8..4b09b73525a 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -1971,21 +1971,60 @@ test_expect_success '--update-refs: do not delete refs if all update-ref are rem
 	git branch -f second HEAD~3 &&
 	git branch -f third HEAD~1 &&
 	git branch -f tip &&
+
+	test_commit test-refs-not-removed &&
+	git commit --amend --fixup first &&
+
+	git rev-parse first second third tip no-conflict-branch >expect-oids &&
+
 	(
 		set_cat_todo_editor &&
-		test_must_fail git rebase -i --update-refs base >todo.raw &&
+		test_must_fail git rebase -i \
+			--autosquash --update-refs \
+			base >todo.raw &&
 		sed -e "/^update-ref/d" <todo.raw >todo
 	) &&
 	(
 		set_replace_editor todo &&
-		git rebase -i --update-refs base
+		git rebase -i --autosquash --update-refs base
 	) &&
 
-	test_cmp_rev HEAD~3 refs/heads/first &&
-	test_cmp_rev HEAD~3 refs/heads/second &&
-	test_cmp_rev HEAD~1 refs/heads/third &&
-	test_cmp_rev HEAD refs/heads/tip &&
-	test_cmp_rev HEAD refs/heads/no-conflict-branch
+	git rev-parse first second third tip no-conflict-branch >actual-oids &&
+	test_cmp expect-oids actual-oids
+'
+
+test_expect_success '--update-refs: do not delete refs if all update-ref are removed and some re-added' '
+	git checkout -b test-refs-not-removed2 no-conflict-branch &&
+	git branch -f base HEAD~4 &&
+	git branch -f first HEAD~3 &&
+	git branch -f second HEAD~3 &&
+	git branch -f third HEAD~1 &&
+	git branch -f tip &&
+
+	test_commit test-refs-not-removed2 &&
+	git commit --amend --fixup first &&
+
+	git rev-parse first second third >expect-oids &&
+
+	(
+		set_cat_todo_editor &&
+		test_must_fail git rebase -i \
+			--autosquash --update-refs \
+			base >todo.raw &&
+		sed -e "/^update-ref/d" <todo.raw >todo
+	) &&
+	echo "break" >>todo &&
+	(
+		set_replace_editor todo &&
+		git rebase -i --autosquash --update-refs base &&
+		echo "update-ref refs/heads/tip" >todo &&
+		git rebase --edit-todo &&
+		git rebase --continue
+	) &&
+
+	git rev-parse first second third >actual-oids &&
+	test_cmp expect-oids actual-oids &&
+	test_cmp_rev HEAD tip
 '
 
 test_expect_success '--update-refs: check failed ref update' '

--- >8 ---

Thanks,
-Stolee
Previous: Phillip WoodNext: Victoria Dye
Message 13 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.