git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Subject: Re: [PATCH 3/7] update-index: use unmerge_index_entry() to support removal
Date: Mon, 31 Jul 2023 16:14:06 -0700	[thread overview]
Message-ID: <xmqqleev3c8x.fsf@gitster.g> (raw)
In-Reply-To: <20230731224409.4181277-4-gitster@pobox.com> (Junio C. Hamano's message of "Mon, 31 Jul 2023 15:44:05 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> @@ -122,6 +128,8 @@ test_expect_success 'add records checkout -m undoes' '
>  test_expect_success 'unmerge with plumbing' '
>  	prime_resolve_undo &&
>  	git update-index --unresolve fi/le &&
> +	git ls-files --resolve-undo fi/le >actual &&
> +	test_must_be_empty actual &&
>  	git ls-files -u >actual &&
>  	test_line_count = 3 actual
>  '

This addition, and matching invocations of "ls-files --resolve-undo"
in the next tests, are not explained in the proposed log message.

The reason for the addition is because "update-index --unresolve"
tests did not make sure that resolve-undo records that are used to
recreate conflicted states are removed from the index, like simiar
tests for "checkout --merge".  As we are changing the implementation
to unmerge index entries, we do not want to regress and these are
filling the gap of the test coverage.

I've clarified it in the draft for the next iteration.

	Side note: careful audience may have noticed this already,
	but yes, this is setting an example of the recent update to
	"my patch was sent, now what?" document, where we discourage
	sending rerolls without giving readers enough time to digest
	the first iteration, and instead tell them to note what will
	change in their next iteration.

> @@ -130,6 +138,27 @@ test_expect_success 'unmerge can be done even after committing' '
>  	prime_resolve_undo &&
>  	git commit -m "record to nuke MERGE_HEAD" &&
>  	git update-index --unresolve fi/le &&
> +	git ls-files --resolve-undo fi/le >actual &&
> +	test_must_be_empty actual &&
> +	git ls-files -u >actual &&
> +	test_line_count = 3 actual
> +'
> +
> +test_expect_success 'unmerge removal' '
> +	prime_resolve_undo remove &&
> +	git update-index --unresolve fi/le &&
> +	git ls-files --resolve-undo fi/le >actual &&
> +	test_must_be_empty actual &&
> +	git ls-files -u >actual &&
> +	test_line_count = 3 actual
> +'
> +
> +test_expect_success 'unmerge removal after committing' '
> +	prime_resolve_undo remove &&
> +	git commit -m "record to nuke MERGE_HEAD" &&
> +	git update-index --unresolve fi/le &&
> +	git ls-files --resolve-undo fi/le >actual &&
> +	test_must_be_empty actual &&
>  	git ls-files -u >actual &&
>  	test_line_count = 3 actual
>  '

  reply	other threads:[~2023-07-31 23:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-31 22:44 [PATCH 0/7] unresolve removal Junio C Hamano
2023-07-31 22:44 ` [PATCH 1/7] update-index: do not read HEAD and MERGE_HEAD unconditionally Junio C Hamano
2023-07-31 22:44 ` [PATCH 2/7] resolve-undo: allow resurrecting conflicted state that resolved to deletion Junio C Hamano
2023-07-31 22:44 ` [PATCH 3/7] update-index: use unmerge_index_entry() to support removal Junio C Hamano
2023-07-31 23:14   ` Junio C Hamano [this message]
2023-07-31 22:44 ` [PATCH 4/7] update-index: remove stale fallback code for "--unresolve" Junio C Hamano
2023-07-31 22:44 ` [PATCH 5/7] checkout/restore: refuse unmerging paths unless checking out of the index Junio C Hamano
2023-07-31 22:44 ` [PATCH 6/7] checkout/restore: add basic tests for --merge Junio C Hamano
2023-07-31 22:44 ` [PATCH 7/7] checkout: allow "checkout -m path" to unmerge removed paths Junio C Hamano
2023-08-04 19:03 ` [PATCH 0/7] unresolve removal Taylor Blau

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

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

  git send-email \
    --in-reply-to=xmqqleev3c8x.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    /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.
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 NNTP newsgroup(s).