git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Elijah Newren <newren@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/2] read-cache: fix directory/file conflict handling in read_index_unmerged()
Date: Wed, 11 Jul 2018 10:03:03 -0700	[thread overview]
Message-ID: <xmqqsh4p3dtk.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20180711051834.28181-3-newren@gmail.com> (Elijah Newren's message of "Tue, 10 Jul 2018 22:18:34 -0700")

Elijah Newren <newren@gmail.com> writes:

>     The _only_ reason we want to keep a previously unmerged entry in the
>     index at stage #0 is so that we don't forget the fact that we have
>     corresponding file in the work tree in order to be able to remove it
>     when the tree we are resetting to does not have the path.
> ...
> So, that's the intended purpose of this function.  The problem is that
> when directory/files conflicts are present, trying to add the file to the
> index at stage 0 fails (because there is still a directory in the way),
> and the function returns early with a -1 return code to signify the error.
> As noted above, none of the callers who want the drop-to-stage-0 behavior
> check the return status, though, so this means all remaining unmerged
> entries remain in the index and the callers proceed assuming otherwise.

Nicely analysed and explained so far.

> ...  The temporary simultaneous appearance of the
> directory and file entries in the index will be removed by the callers
> before they attempt to write the index anywhere.

But this part makes me feel a bit uneasy, as I find this "will be
removed" a bit hand-wavy.  There are two such callers.  "am --skip"
and "reset".  

The former uses am.c::fast_forward_to that calls unpack_trees() to
two-way merge (aka "switch to the other branch") and these entries
with CE_CONFLICTED flag get removed in merged/deleted_entry().

"reset" (all variants) call unpack_trees() on the index prepared
with read_cache_unmerged(), and the unmerged entries that are marked
with CE_CONFLICTED bit get removed the same way.

So perhaps before "before they attempt to", saying "by calling
unpack_trees(), which excludes these unmerged entries marked with
CE_CONFLICTED flag from the resulting index," or something like that
would help uneasy readers?

> Signed-off-by: Elijah Newren <newren@gmail.com>
> ---
>  read-cache.c                         | 13 ++++++++-----
>  t/t1015-read-index-unmerged.sh       |  8 ++++----
>  t/t6020-merge-df.sh                  |  3 ---
>  t/t6042-merge-rename-corner-cases.sh |  1 -
>  4 files changed, 12 insertions(+), 13 deletions(-)
>
> diff --git a/read-cache.c b/read-cache.c
> index 372588260..666d295a5 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -2632,10 +2632,13 @@ int write_locked_index(struct index_state *istate, struct lock_file *lock,
>  
>  /*
>   * Read the index file that is potentially unmerged into given
> - * index_state, dropping any unmerged entries.  Returns true if
> - * the index is unmerged.  Callers who want to refuse to work
> - * from an unmerged state can call this and check its return value,
> - * instead of calling read_cache().
> + * index_state, dropping any unmerged entries to stage #0 (potentially
> + * resulting in a path appearing as both a file and a directory in the
> + * index; the caller is responsible to clear out the extra entries
> + * before writing the index to a tree).  Returns true if the index is
> + * unmerged.  Callers who want to refuse to work from an unmerged
> + * state can call this and check its return value, instead of calling
> + * read_cache().
>   */
>  int read_index_unmerged(struct index_state *istate)
>  {
> @@ -2658,7 +2661,7 @@ int read_index_unmerged(struct index_state *istate)
>  		new_ce->ce_flags = create_ce_flags(0) | CE_CONFLICTED;
>  		new_ce->ce_namelen = len;
>  		new_ce->ce_mode = ce->ce_mode;
> -		if (add_index_entry(istate, new_ce, 0))
> +		if (add_index_entry(istate, new_ce, ADD_CACHE_SKIP_DFCHECK))
>  			return error("%s: cannot drop to stage #0",
>  				     new_ce->name);
>  	}
> diff --git a/t/t1015-read-index-unmerged.sh b/t/t1015-read-index-unmerged.sh
> index bbd64587c..5034ed931 100755
> --- a/t/t1015-read-index-unmerged.sh
> +++ b/t/t1015-read-index-unmerged.sh
> @@ -30,7 +30,7 @@ test_expect_success 'setup modify/delete + directory/file conflict' '
>  	)
>  '
>  
> -test_expect_failure 'read-tree --reset cleans unmerged entries' '
> +test_expect_success 'read-tree --reset cleans unmerged entries' '
>  	test_when_finished "git -C df_plus_modify_delete clean -f" &&
>  	test_when_finished "git -C df_plus_modify_delete reset --hard" &&
>  	(
> @@ -45,7 +45,7 @@ test_expect_failure 'read-tree --reset cleans unmerged entries' '
>  	)
>  '
>  
> -test_expect_failure 'One reset --hard cleans unmerged entries' '
> +test_expect_success 'One reset --hard cleans unmerged entries' '
>  	test_when_finished "git -C df_plus_modify_delete clean -f" &&
>  	test_when_finished "git -C df_plus_modify_delete reset --hard" &&
>  	(
> @@ -87,7 +87,7 @@ test_expect_success 'setup directory/file conflict + simple edit/edit' '
>  	)
>  '
>  
> -test_expect_failure 'git merge --abort succeeds despite D/F conflict' '
> +test_expect_success 'git merge --abort succeeds despite D/F conflict' '
>  	test_when_finished "git -C df_plus_edit_edit clean -f" &&
>  	test_when_finished "git -C df_plus_edit_edit reset --hard" &&
>  	(
> @@ -103,7 +103,7 @@ test_expect_failure 'git merge --abort succeeds despite D/F conflict' '
>  	)
>  '
>  
> -test_expect_failure 'git am --skip succeeds despite D/F conflict' '
> +test_expect_success 'git am --skip succeeds despite D/F conflict' '
>  	test_when_finished "git -C df_plus_edit_edit clean -f" &&
>  	test_when_finished "git -C df_plus_edit_edit reset --hard" &&
>  	(
> diff --git a/t/t6020-merge-df.sh b/t/t6020-merge-df.sh
> index 2af1beec5..46b506b3b 100755
> --- a/t/t6020-merge-df.sh
> +++ b/t/t6020-merge-df.sh
> @@ -89,9 +89,6 @@ test_expect_success 'modify/delete + directory/file conflict' '
>  '
>  
>  test_expect_success 'modify/delete + directory/file conflict; other way' '
> -	# Yes, we really need the double reset since "letters" appears as
> -	# both a file and a directory.
> -	git reset --hard &&
>  	git reset --hard &&
>  	git clean -f &&
>  	git checkout modify^0 &&
> diff --git a/t/t6042-merge-rename-corner-cases.sh b/t/t6042-merge-rename-corner-cases.sh
> index 1cbd946fc..583e68997 100755
> --- a/t/t6042-merge-rename-corner-cases.sh
> +++ b/t/t6042-merge-rename-corner-cases.sh
> @@ -323,7 +323,6 @@ test_expect_success 'rename/directory conflict + content merge conflict' '
>  	(
>  		cd rename-directory-1 &&
>  
> -		git reset --hard &&
>  		git reset --hard &&
>  		git clean -fdqx &&

  reply	other threads:[~2018-07-11 17:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-11  5:18 [PATCH 0/2] Address recovery failures with directory/file conflicts Elijah Newren
2018-07-11  5:18 ` [PATCH 1/2] t1015: demonstrate directory/file conflict recovery failures Elijah Newren
2018-07-11  9:21   ` Eric Sunshine
2018-07-11 18:23     ` Elijah Newren
2018-07-11  5:18 ` [PATCH 2/2] read-cache: fix directory/file conflict handling in read_index_unmerged() Elijah Newren
2018-07-11 17:03   ` Junio C Hamano [this message]
2018-07-11 18:24     ` Elijah Newren
2018-07-13 16:33 ` [PATCH v2 0/2] Address recovery failures with directory/file conflicts Elijah Newren
2018-07-13 16:33   ` [PATCH v2 1/2] t1015: demonstrate directory/file conflict recovery failures Elijah Newren
2018-07-13 16:33   ` [PATCH v2 2/2] read-cache: fix directory/file conflict handling in read_index_unmerged() Elijah Newren
2018-07-13 16:45   ` [PATCH v2 0/2] Address recovery failures with directory/file conflicts Elijah Newren
2018-07-31 17:12   ` [PATCH v3 " Elijah Newren
2018-07-31 17:12     ` [PATCH v3 1/2] t1015: demonstrate directory/file conflict recovery failures Elijah Newren
2018-07-31 17:12     ` [PATCH v3 2/2] read-cache: fix directory/file conflict handling in read_index_unmerged() Elijah Newren

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=xmqqsh4p3dtk.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=newren@gmail.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).