git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Derrick Stolee <derrickstolee@github.com>
To: phillip.wood@dunelm.org.uk, Victoria Dye <vdye@github.com>,
	git@vger.kernel.org
Cc: Phillip Wood <phillip.wood123@gmail.com>,
	"herr . kaste" <herr.kaste@gmail.com>,
	Taylor Blau <me@ttaylorr.com>
Subject: Re: [PATCH] rebase --update-refs: avoid unintended ref deletion
Date: Sun, 6 Nov 2022 21:39:56 -0500	[thread overview]
Message-ID: <20221c91-e473-c66a-a0bd-b650a6626e31@github.com> (raw)
In-Reply-To: <6c022318-afc0-2ad7-b29c-ccb87f2f2e94@dunelm.org.uk>

On 11/4/22 4:12 PM, Phillip Wood wrote:
> 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!

>> 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).

>> +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

  reply	other threads:[~2022-11-07  2:40 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-20 17:01 rebase -i --update-refs can lead to deletion of branches herr.kaste
2022-10-20 20:49 ` Erik Cervin Edin
2022-11-03  9:32 ` Phillip Wood
2022-11-03 15:25   ` herr.kaste
2022-11-03 16:52     ` Erik Cervin Edin
2022-11-04  0:31 ` Victoria Dye
2022-11-04 10:40   ` Phillip Wood
2022-11-04 15:28     ` Victoria Dye
2022-11-04 16:57       ` [PATCH] rebase --update-refs: avoid unintended ref deletion Victoria Dye
2022-11-04 19:44         ` Taylor Blau
2022-11-04 20:17           ` Phillip Wood
2022-11-04 20:12         ` Phillip Wood
2022-11-07  2:39           ` Derrick Stolee [this message]
2022-11-07 17:47         ` [PATCH v2] " Victoria Dye
2022-11-07 19:17           ` Taylor Blau
2022-11-07 19:25           ` Derrick Stolee
2022-11-08  9:58           ` Phillip Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221c91-e473-c66a-a0bd-b650a6626e31@github.com \
    --to=derrickstolee@github.com \
    --cc=git@vger.kernel.org \
    --cc=herr.kaste@gmail.com \
    --cc=me@ttaylorr.com \
    --cc=phillip.wood123@gmail.com \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=vdye@github.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).